On 03/18/2016 09:52 PM, Jason Ekstrand wrote: > > > On Fri, Mar 4, 2016 at 5:43 AM, Andres Gomez <[email protected] > <mailto:[email protected]>> 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 :-)
That might be an interesting extension, should anyone ever care. *shrug* > 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 ;-) I would suggest submitting a bug against glslang as well. > 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
