[Mesa-dev] About the usage of the "flat" interpolation qualifier with input (unsigned) integers and doubles in fragment shaders

[Jason Ekstrand]

On Fri, Mar 4, 2016 at 5:43 AM, Andres Gomez <agomez at igalia.com> wrote:

> Hi,
>
> as complementary work to the one done to "Add FP64 support to the i965
> shader backends" at:
> https://bugs.freedesktop.org/show_bug.cgi?id=92760
>
> I've been working to add piglit tests that would check the new features
> added by this addition.
>
> Checking the specification of the extension, when talking about inputs,
> the extension instructs that any fragment input being a double or
> derived type must be qualified with the interpolation qualifier "flat".
>
> This extends the restriction that already existed for signed and
> unsigned integers to doubles too.
>
> In following versions of the spec, when doubles are already part of it
> we can read:
>
> "
> Fragment shader inputs that are signed or unsigned integers, integer
> vectors, or any double-precision floating-point type must be qualified
> with the interpolation qualifier flat.
> "
>
> The specification doesn't explicitly say it, but as far as I understand,
> it is reasonable to think that the restriction applies to input
> variables in the form of arrays or members of structures of these types.
>

Yes, I think that's a reasonable assumption.  The reason it's required for
integers is because you can't interpolate them at all.  Some hardware may
also not support interpolating doubles so they are included in the
statement.  Incidentally, we could implement it in i965 because Intel
hardware does its interpolation in the shader.  That does not, however,
mean that we should :-)


> In fact, current implementation already fails on compilation if a
> non-flat integer is in a fragment input as an array or a struct member.
> The same happens with doubles (llvmpipe).
>
> It is also reasonable to think that the restriction would also apply to
> input interface blocks holding variables of these types.
>
> However, the compilation doesn't fail when using a non-flat integer or a
> double. On execution, the integer version just gives bogus values while,
> with doubles, it crashes.
>
> --
>
> The situation with the glslangValidator is (it doesn't support doubles):
>       * When using a non-flat integer as a fragment input in the form of
>         an array or as a member of a struct it fails with an error of
>         the type:
>
> int' : must be qualified as flat in
>
>       * When using a non-flat integer as a fragment input in the form of
>         a member of an interface block it succeeds on compilation.
>

Glslang is an ok compiler, but I wouldn't give it too much weight.  Just
because it's billed as a "reference compiler" doesn't mean you should trust
it to get all the edge cases right.  I've personally fixed enough bugs in
it to now better ;-)


> The situation with nvidia proprietary driver is:
>       * When using a non-flat integer as a fragment input in the form of
>         a scalar, an array, a member of a struct or a member of an
>         interface block it doesn't fail on compilation but on linkage
>         with an error of the type:
>
> error C5215: Integer varying <variable> must be flat
>
>       * When using a double as a fragment input in the form of a scalar
>         or an array it fails on compilation with an error of the type:
>
> error C7570: 64 bit input '<variable>' should be flat
>
>       * When using a double as a fragment input in the form of a a
>         member of a struct or a member of an interface block it doesn't
>         fail. Actually, it seems to do some kind of interpolation.
>
> --
>
> Hence, based on this, my proposal would be:
>       * To enforce the usage of the "flat" qualifier when in a member of
>         an input block interface in a fragment shader for (unsigned)
>         integers and doubles.
>

Agreed.  That seems like the right thing to do.


>       * Open a bug in Khronos specs bugzilla about the ambiguity of
>         this.
>

Done.  Khronos bug #15671.


>
>
> Opinions?
>
> --
> Br,
>
> Andres
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160318/44289cdf/attachment.html>