Re: [Mesa-dev] Using the 'f' suffix to create a float from an integer literal
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(? > > > 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 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
Re: [Mesa-dev] Using the 'f' suffix to create a float from an integer literal
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(? > 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. :) > - Neil > > Iago Toral 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
Re: [Mesa-dev] Using the 'f' suffix to create a float from an integer literal
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(? 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
Re: [Mesa-dev] Using the 'f' suffix to create a float from an integer literal
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
Re: [Mesa-dev] Using the 'f' suffix to create a float from an integer literal
> The $64,000 question: What do other GLSL compilers (including, > perhaps,glslang) do? :) Shouldn't this be the "$1e6f question"? Jose From: mesa-dev on behalf of Iago Toral Sent: 20 November 2014 07:08 To: Ian Romanick Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] Using the 'f' suffix to create a float from an integer literal 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! Iago > > Thanks, > > Iago > > > > [1] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opengl.org_wiki_Data-5FType-5F-28GLSL-29&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=-vNxCjRApDMGfEN7OH0gdQY45tX4GCnJezazsrd2DNg&s=v-iOTBhqyw5b2dul6DNiwG3s4jGuIujxKjaxWWGRqc8&e= > > > > ___ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=-vNxCjRApDMGfEN7OH0gdQY45tX4GCnJezazsrd2DNg&s=YtsceeKLkQZUT8ymwqfviOL4cuiZKwMSPLqvO44zptE&e= > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=-vNxCjRApDMGfEN7OH0gdQY45tX4GCnJezazsrd2DNg&s=YtsceeKLkQZUT8ymwqfviOL4cuiZKwMSPLqvO44zptE&e= ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Using the 'f' suffix to create a float from an integer literal
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! Iago > > Thanks, > > Iago > > > > [1] https://www.opengl.org/wiki/Data_Type_%28GLSL%29 > > > > ___ > > 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
Re: [Mesa-dev] Using the 'f' suffix to create a float from an integer literal
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? > 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. > Thanks, > Iago > > [1] https://www.opengl.org/wiki/Data_Type_%28GLSL%29 > > ___ > 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
