[Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries

[Ilia Mirkin]

As I recall, I wanted to fix the piglits when doing GS or
ARB_viewport_array for nv50. I believe Ian shot it down. This was ~1-2
years ago, so I don't remember the specifics.

  -ilia

On Tue, Dec 1, 2015 at 2:37 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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
>>
>