On Thu, 2014-11-20 at 09:33 -0800, Ian Romanick wrote: > On 11/20/2014 05:33 AM, Neil Roberts wrote: > > For what it's worth, I did a quick grep through the internal and public > > shader-db and I couldn't find anything using this. > > > > git grep -P '\b(?<!e[+-])(?<![.0-9])[0-9]+f\b' > > > > If AMD disallows it then it seems like it would be reasonably safe to > > disallow it in Mesa too. > > > > GCC disallows it too which could be an indication that people won't have > > a habit of using it. > > So... the GLSL spec actually follows C? Then we should definitely > follow the spec, and there's no need for a GLSL spec bug. If AMD > disallows it, then there are not likely to be any applications that > depend on it... so I agree with Neil that we're safe to disallow it too. > > I'm still curious about glslang... if glslang allows it, I'll file a bug > against glslang. :)
glslang follows the spec, it spits an error and fails to compile a shader that uses that syntax. Iago > > - Neil > > > > Iago Toral <ito...@igalia.com> writes: > > > >> On Thu, 2014-11-20 at 08:08 +0100, Iago Toral wrote: > >>> On Wed, 2014-11-19 at 10:27 -0800, Ian Romanick wrote: > >>>> On 11/19/2014 03:47 AM, Iago Toral Quiroga wrote: > >>>>> Hi, > >>>>> > >>>>> I came across a GLSL test that checks that doing something like this in > >>>>> a shader should fail: > >>>> > >>>> Is this one of the dEQP tests? > >>> > >>> Yes. > >>> > >>>>> float value = 1f; > >>>> > >>>> It seems like we have a test related to this in piglit somewhere... it > >>>> looks like tests/shaders/glsl-floating-constant-120.shader_test uses > >>>> that syntax, but it's not explicitly testing that feature. > >>>> > >>>>> However, this works fine in Mesa. Checking the spec I see: > >>>>> > >>>>> Floating-point constants are defined as follows. > >>>>> floating-constant: > >>>>> fractional-constant exponent-part(opt) floating-suffix(opt) > >>>>> digit-sequence exponent-part floating-suffix(opt) > >>>>> fractional-constant: > >>>>> digit-sequence . digit-sequence > >>>>> digit-sequence . > >>>>> . digit-sequence > >>>>> exponent-part: > >>>>> e sign(opt) digit-sequence > >>>>> E sign(opt) digit-sequence > >>>>> sign: one of > >>>>> + - > >>>>> digit-sequence: > >>>>> digit > >>>>> digit-sequence digit > >>>>> floating-suffix: one of > >>>>> f F > >>>>> > >>>>> which suggests that the test is correct and Mesa has a bug. According to > >>>>> the above rules, however, something like this is fine: > >>>>> > >>>>> float f = 1e2f; > >>>>> > >>>>> which I find kind of weird if the other case is not valid, so I wonder > >>>>> if there is a bug in the spec or this is on purpose for some reason that > >>>>> I am missing. > >>>>> > >>>>> Then, to make matters worse, I read this in opengl.org wiki [1]: > >>>>> > >>>>> "A numeric literal that uses a decimal is by default of type float. To > >>>>> create a float literal from an integer value, use the suffix f or F as > >>>>> in C/C++." > >>>>> > >>>>> which contradicts the spec and the test and is aligned with the current > >>>>> way Mesa works. > >>>>> > >>>>> So: does anyone know what version is right? Could this be a bug in the > >>>>> spec? and if it is not, do we want to change the behavior to follow the > >>>>> spec as it is now? > >>>> > >>>> The $64,000 question: What do other GLSL compilers (including, perhaps, > >>>> glslang) do? This seems like one of the cases where nobody is likely to > >>>> follow the spec, and some application will depend on that. If that's > >>>> the case, I'll submit a spec bug. > >>> > >>> Good point. I'll try to check a few cases and reply here. Thanks! > >> > >> I did a quick test on AMD Radeon and nVidia proprietary drivers since I > >> had these easily available. AMD fails to compile (so it follows the > >> spec) but nVidia works (so same case as Mesa). > >> > >> This confirms your guess: different drivers are doing different things. > >> Is this enough to file a spec bug? I imagine that the result on glslang > >> won't change anything, but I can try to install it and test there too if > >> you think that's interesting anyway. > >> > >> Iago > >> > >> _______________________________________________ > >> mesa-dev mailing list > >> mesa-dev@lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
