[Mesa-dev] LAYER_PROVOKING_VERTEX and VIEWPORT_INDEX_PROVOKING_VERTEX queries
sroland at vmware.com
Tue Dec 1 10:41:34 PST 2015
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...
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 = ...
> gl_Position = ...
> 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.
> 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
>> 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.
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
More information about the mesa-dev