[Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

[Roland Scheidegger]

Thinking about this, are there really apps out there which get it wrong?
piglits can be fixed easily.
If some app did that seemingly wrong, it might have been due to the
bogus query. That is, if it switched to first provoking vertex
convention, then asked for the provoking vertex layer, it would have
gotten first vertex convention. Theoretically it might then have used
shaders which took that into account (and even regardless if it later
switched back to last vertex convention or not). But assuming
unitialized outputs have to be copied over from other vertices really
seems a bit strange...

Roland


Am 01.12.2015 um 19:41 schrieb Roland Scheidegger:
> I don't think that will work with draw (can't see why it would), and
> don't plan on fixing it (at least not now).
> In d3d10, this of course would work (at least if you emit the layer per
> prim), because it requires the layer info to be taken from the provoking
> (first) vertex. But that doesn't seem to be very sane for GL...
> 
> Roland
> 
> 
> 
> Am 01.12.2015 um 19:25 schrieb Ilia Mirkin:
>> Irrespective of any spec lawyering you might do, we have some piglit
>> tests which basically assume that things like
>>
>> gl_Layer = foo;
>> gl_Position = ...
>> EmitVertex();
>> gl_Position = ...
>> EmitVertex();
>>
>> will always work. I believe this was based on the theory that some
>> applications actually do this, although tbh I don't remember the
>> details. We ended up adding a "latch" in nouveau/codegen to just
>> always re-emit the previously-computed layer at EmitVertex() time.
>>
>>   -ilia
>>
>>
>>
>> On Tue, Dec 1, 2015 at 12:43 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>> Trying to fix some draw bugs with layer/vp outputs (and clipping), I was
>>> wondering if GL actually guarantees sane results if the layer/vp index
>>> isn't the same on all vertices. And sure it seems it does, albeit it's
>>> implementation-dependent. Specifically (from gl 4.4 core, page 388)
>>>
>>> "viewport index is implementation-dependent and thus portable
>>> applications will assign the same layer and viewport index for all
>>> vertices in a primitive. The vertex conventions followed for gl_Layer
>>> and gl_ViewportIndex may be determined by calling GetIntegerv with the
>>> symbolic constants LAYER_PROVOKING_VERTEX and
>>> VIEWPORT_INDEX_PROVOKING_VERTEX, respectively. For either query, if the
>>> value returned is PROVOKING_VERTEX, then vertex selection follows the
>>> convention specified by ProvokingVertex (see section 13.4). If the value
>>> returned is FIRST_VERTEX_CONVENTION, selection is always taken from the
>>> first vertex of a primitive. If the value returned is
>>> LAST_VERTEX_CONVENTION, the selection is always taken from the last
>>> vertex of a primitive. If the value returned is UNDEFINED_VERTEX, the
>>> selection is not guaranteed to be taken from any specific vertex in the
>>> primitive."
>>>
>>> However, what mesa does is just return Light.ProvokingVertex. This means
>>> that if you switch the provoking vertex, the result will be different,
>>> which seems quite inappropriate for this implementation-dependent query.
>>> Albeit I'm not sure what the result really should be, that is if all
>>> drivers will do the same - I guess though UNDEFINED_VERTEX would always
>>> be correct.
>>>
>>>
>>> Roland
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIBaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=IChBdIDeVZLxc6pAX_ISVsm1apkVwcteaBV8hJWm02U&s=Iu2Nb_m2ioE0OGuK-t0WJzRve4z6PddDe_OPIswS9-w&e= 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>