[Mesa-dev] Using the 'f' suffix to create a float from an integer literal
Iago Toral
itoral at igalia.com
Thu Nov 20 01:05:34 PST 2014
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
More information about the mesa-dev
mailing list