[Mesa-dev] [PATCH] etnaviv: Fix point sprite issue on HALTI0

[Wladimir J. van der Laan]

On Thu, Nov 16, 2017 at 12:26:05PM -0500, Ilia Mirkin wrote:
> On Thu, Nov 16, 2017 at 7:15 AM, Wladimir <laanwj at gmail.com> wrote:

> 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.

Thanks for the info - I know about nothing about legacy GL, too long
ago for me.

For Vivantes (HALTI4-) it is the case that any varying can be replaced by the
point coordinate. This is used for the gl_PointCoord as well. So far so good.

However the trouble is in how this interacts with flat shading. The same flag
is used to mark varyings that should be interpolated when using flat
shading (apparently everything except COLOR?).

Currently the criterion for setting the flag is !=SEMANTIC_COLOR. This
works for polygons, by allowing non-color varyings override flat shading, but
breaks when rendering points, because we want GENERIC varyings to be simply
passed through in that case - not replaced with the point coordinate!

Which gives us the following varying state, for flat shaded and smooth polygons
and for points (where shading model is irrelevant) respectively:

         GENERIC  T/PCOORD COLOR
Flat        1        1       0
Smooth      x        x       x
Points      0        1       0

(0=VARYING_USE_USED, 1=VARYING_USE_POINTCOORD, x=dont_care)

Which is annoying as it means that shader state now depends on either the kind
of primitive (which is per-draw), or the shading model (which is part of
rasterizer state).

Thinking of it, the latter is also an option, at least we don't have to
"smuggle" per-draw info into the state emit call. But it's still
quite more involved to fix than I expected :(

Regards,
Wladimir