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: https://patchwork.freedesktop.org/patch/202046/
> > 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). Roland > best, > Gert > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev