[Mesa-dev] [PATCH 1/3] mesa: Fix typos in transform feedback error messages.

Paul Berry stereotype441 at gmail.com
Tue Jan 3 19:48:25 PST 2012


On 3 January 2012 18:51, Paul Berry <stereotype441 at gmail.com> wrote:

> On 3 January 2012 18:16, Eric Anholt <eric at anholt.net> wrote:
>
>>
>> This series is Reviewed-by: Eric Anholt <eric at anholt.net>
>>
>> With this and the fix I have for glGetTransformFeedbackVarying(), I
>> think we should be passing the oglc tests, except for one more case:
>> They try to ask for whole arrays to be fed back, without [] in the
>> declaration.  The clearest text I could find on this point was a
>> RESOLUTION: in the spec, but it kind of sounded to me like the
>> resolution was about working around "how to I get feedback from my huge
>> amount of varying data when I have so few TFB attributes available?"
>> Did you end up testing whether other drivers accepted non-subscripted
>> TFB varyings for varying arrays?
>>
>
> No, I didn't write any tests of non-subscripted arrays.  My interpretation
> of the spec had been that they weren't allowed, but now that I'm re-reading
> it, I'm reconsidering.  I'll investigate on the nVidia proprietary linux
> driver and let you know what I find out.
>

Argh, nVidia supports non-subscripted arrays just fine, even on
gl_ClipDistance.

I had been hoping we wouldn't have to deal with this, based on the same
RESOLUTION you saw.  But in retrospect that was wishful thinking.  It's
clear from the rest of the EXT_transform_feedback spec that non-subscripted
arrays have always been intended to work.  The clincher is the "size"
argument of GetTransformFeedbackVarying(), which would be pointless if
non-subscripted arrays weren't allowed.

I feel responsible for this bug since my wishful thinking prevented it from
being discovered earlier.  I'll get a fix, and some tests, out to the list
ASAP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20120103/e67efd3a/attachment.htm>


More information about the mesa-dev mailing list