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

[Ilia Mirkin]

On Thu, Nov 16, 2017 at 7:15 AM, Wladimir <laanwj at 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