On Thu, Nov 16, 2017 at 7:15 AM, Wladimir <laa...@gmail.com> wrote: >> I think it would be reasonable to re-emit the shader state (or maybe >> just the varyings) when the primitive type changes from points to >> non-points. It virtually never happens that the same shader combo is >> used for points and non-points. > > Thinking about it, this might even simplify some contorted code we > currently have in the emit sequence with regard to pointsize VS > outputs. Which becomes even worse in GC7000 where there's more (USC / > buffering related) state depending on the exact number of VS outputs. > > Hmm that state depends on point_size_per_vertex, not whether we're > rendering points. So I guess we'd want to re-link the shader if: > > - switching from point to non-point rendering, or vice versa > - if rendering points AND point_size_per_vertex changes > > Though as for the latter I have no clue where vivantes get the point > size from if !point_size_per_vertex, currently we don't handle > pipe_rasterizer_state->point_size at all, we pretty much just assume > point_size_per_vertex.
I'm probably just saying stuff that you already know, but ... I'll say it anyways: The point of the texcoord semantics is precisely point sprite replacement. NVIDIA hardware (Fermi+) can only do point sprite replacement on certain specially-located varyings, hence the texcoord semantic was created. (And nv30 also has similar restrictions. nv50 is unconstrained, go figure.) In legacy GL, only gl_TexCoord varyings may be replaced by point sprites, and the gl_PointCoord is handled separately. I don't think ES has an equivalent of point sprite coord replacements. Hardware without that restriction should probably not use the texcoord semantic and just use GENERIC for everything. Cheers, -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
