<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 5:43 AM, Andres Gomez <span dir="ltr"><<a href="mailto:agomez@igalia.com" target="_blank">agomez@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
as complementary work to the one done to "Add FP64 support to the i965<br>
shader backends" at:<br>
<a href="https://bugs.freedesktop.org/show_bug.cgi?id=92760" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=92760</a><br>
<br>
I've been working to add piglit tests that would check the new features<br>
added by this addition.<br>
<br>
Checking the specification of the extension, when talking about inputs,<br>
the extension instructs that any fragment input being a double or<br>
derived type must be qualified with the interpolation qualifier "flat".<br>
<br>
This extends the restriction that already existed for signed and<br>
unsigned integers to doubles too.<br>
<br>
In following versions of the spec, when doubles are already part of it<br>
we can read:<br>
<br>
"<br>
Fragment shader inputs that are signed or unsigned integers, integer<br>
vectors, or any double-precision floating-point type must be qualified<br>
with the interpolation qualifier flat.<br>
"<br>
<br>
The specification doesn't explicitly say it, but as far as I understand,<br>
it is reasonable to think that the restriction applies to input<br>
variables in the form of arrays or members of structures of these types.<br></blockquote><div><br></div><div>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 :-)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In fact, current implementation already fails on compilation if a<br>
non-flat integer is in a fragment input as an array or a struct member.<br>
The same happens with doubles (llvmpipe).<br>
<br>
It is also reasonable to think that the restriction would also apply to<br>
input interface blocks holding variables of these types.<br>
<br>
However, the compilation doesn't fail when using a non-flat integer or a<br>
double. On execution, the integer version just gives bogus values while,<br>
with doubles, it crashes.<br>
<br>
--<br>
<br>
The situation with the glslangValidator is (it doesn't support doubles):<br>
      * When using a non-flat integer as a fragment input in the form of<br>
        an array or as a member of a struct it fails with an error of<br>
        the type:<br>
<br>
int' : must be qualified as flat in<br>
<br>
      * When using a non-flat integer as a fragment input in the form of<br>
        a member of an interface block it succeeds on compilation.<br></blockquote><div><br></div><div>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 ;-)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The situation with nvidia proprietary driver is:<br>
      * When using a non-flat integer as a fragment input in the form of<br>
        a scalar, an array, a member of a struct or a member of an<br>
        interface block it doesn't fail on compilation but on linkage<br>
        with an error of the type:<br>
<br>
error C5215: Integer varying <variable> must be flat<br>
<br>
      * When using a double as a fragment input in the form of a scalar<br>
        or an array it fails on compilation with an error of the type:<br>
<br>
error C7570: 64 bit input '<variable>' should be flat<br>
<br>
      * When using a double as a fragment input in the form of a a<br>
        member of a struct or a member of an interface block it doesn't<br>
        fail. Actually, it seems to do some kind of interpolation.<br>
<br>
--<br>
<br>
Hence, based on this, my proposal would be:<br>
      * To enforce the usage of the "flat" qualifier when in a member of<br>
        an input block interface in a fragment shader for (unsigned)<br>
        integers and doubles.<br></blockquote><div><br></div><div>Agreed.  That seems like the right thing to do.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
      * Open a bug in Khronos specs bugzilla about the ambiguity of<br>
        this.<br></blockquote><div><br></div><div>Done.  Khronos bug #15671.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Opinions?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Br,<br>
<br>
Andres<br>
</font></span><br>_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
<br></blockquote></div><br></div></div>