[Mesa-dev] A few fixes for the preprocessor for GLSL 1.30
kenneth at whitecape.org
Fri Feb 22 13:39:49 PST 2013
On 02/22/2013 01:14 PM, Carl Worth wrote:
> Ian Romanick <idr at freedesktop.org> writes:
>> Though, it turns out that this deviates from what C99 specifies.
>> Specifically, the ISO/IEC 9899:TC2 Committee Draft dated May 6, 2005 says:
>> "After all replacements due to macro expansion and the defined unary
>> operator have been performed, all remaining identifiers are replaced
>> with the pp-number 0..."
>> I've submitted a GLSL spec bug.
>> In the mean time, I'd suggest leaving the tests and our implementation
> Hi Ian,
> Back in September, 2011, I did leave the test and implementation as-is.
> Then, in June 2012, I changed the behavior of our implementation, (I
> believe this was in response to an upcoming change in the specification
> you were aware of). At the time, I updated some "make check" tests, but
> failed to update piglit, (leading to bugzilla bug #51631).
> I'd like to fix that now. I can see by comparing the GLSL 4.30
> specification to GLSL 1.30 that the following sentence has been dropped,
> (justifying the currently implemented behavior in Mesa):
> It is an error to use #if or #elif on expressions containing
> undefined macro names, other than as arguments to the
> defined operator.
> But I'd like a little guidance on what to do with the piglit test. We're
> still only support GLSL 1.30 in our implementation, right? Should we be
> supporting the formerly-specified behavior until we start seeing
> "#version 430"?
> Or should we change piglit to just check for the new behavior, even with
> the old version? (You mentioned earlier in this thread that AMD and
> nVidia binary blobs were previously implementing the new behavior
I'd recommend assuming the new behavior in all language versions, with a
comment in the test indicating that both AMD and nVidia's drivers have
this behavior, so it's the de facto standard.
My $0.02 anyway.
More information about the mesa-dev