Hi, Thanks, Jason and Ian, for the feedback. See the patch sent at: https://lists.freedesktop.org/archives/mesa-dev/2016-April/111842.html
Br. On Wed, 2016-03-23 at 14:51 -0700, Ian Romanick wrote: > 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 > -- Br, Andres
signature.asc
Description: This is a digitally signed message part
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
