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

[Ilia Mirkin]

On Thu, Nov 16, 2017 at 1:20 PM, Wladimir J. van der Laan
<laanwj at gmail.com> wrote:
> 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).

I take it your hardware doesn't support setting a different polygon
mode for front and back-facing triangles?

>
> 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 :(

When you say flat shading ... are you talking about like "flat in vec4
bla", or like glShadeModel(GL_FLAT)? If the latter, note that this
only applies to gl_Color / gl_SecondaryColor. Not regular varyings.
The "flat" keyword can apply to any varying, of course.

These are totally separate concepts, I'd really recommend poring over
your traces again to see if you might have missed something. Here's
how it works on Adreno:

a3xx is easy:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/freedreno/a3xx/fd3_program.c#n386

a4xx+ is a little weird:
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/freedreno/a4xx/fd4_program.c#n473
+
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/freedreno/ir3/ir3_compiler_nir.c#n2945

(i.e. you have to load flat inputs specially on a4xx+)

  -ilia