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

Erik Faye-Lund kusmabite at gmail.com
Mon Nov 20 10:34:41 UTC 2017


On Thu, Nov 16, 2017 at 6:26 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> 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.

OpenGL ES 1.x does, through OES_point_sprite. But this should already
use legacy gl_TexCoord varyings. On OpenGL ES 2.0, all we have is
gl_PointCoord. So yeah, OpenGL ES should be covered.


More information about the mesa-dev mailing list