[Mesa-dev] [PATCH 0/3] verify max vertex attrib stride

Roland Scheidegger sroland at vmware.com
Mon Jul 9 12:40:11 UTC 2018

Am 09.07.2018 um 11:51 schrieb Gert Wollny:
> Am Montag, den 09.07.2018, 09:54 +0200 schrieb Erik Faye-Lund:
>> On 06. juli 2018 18:43, Roland Scheidegger wrote:
>>> Personally I think it's _much_ better to lie about the supported GL
>>> version rather than the maximum vertex attrib stride (I don't know
>>> if dEQP would actually have a test which tests for the max stride
>>> also working than just being advertized, which would be way more
>>> relevant and fail in any case).
>> I don't think I agree in this case; OpenGL 4.4 applications that use
>> *exactly* strides of 2048probably won't even check the max-stride, as
>> it's guaranteed to work by the standard anyway. Applications that use
>> *more* might check for this value, but as the query was introduced in
>> 4.4 it's likely that applications will just get a gl-error down an
>> unexpected code-path, which can lead to the wrong attribute bound
>> (possibly pointing to client-memory, which can lead to segfaults).
>> Lying about the max attribute stride will "just" lead to rendering
>> glitches.
> FWIW: The value probably comes from the definition of
> SQ_VTX_CONSTANT_WORD2_0 where a stride is defined as a value of 11 bits
>  that is 0-2047, and when the value is send to the graphics card it
> will be masked to use only these 11 bits, which means when an
> applciation uses a stride of 2048 then the value zero will be uploaded.
Yes,  exactly.
Note that the idea to use 2048 instead came up before:

> Also I seem to remember that the blob advertised OpenGL 4.4 - now
> whether they lied about it, had some special code path, or a value of
> zero is actually interpreted as 2048 (which would actually make sense
> to me), I don't know. - Well, when I get around to it, I'll write a
> piglit that sees what happens in that case ... 
I think stride zero is quite a valid value and is interpreted as such.
Although I'm not sure if Dave actually tried it out (I merely pointed
out there's not actually enough bits in there).


> best, 
> Gert

More information about the mesa-dev mailing list