On 02/08/2016 03:37 PM, Roland Scheidegger wrote: > Am 09.02.2016 um 00:02 schrieb Ian Romanick: >> On 02/08/2016 12:38 PM, Marek Olšák wrote: >>> On Mon, Feb 8, 2016 at 5:08 PM, Tom Stellard <t...@stellard.net> wrote: >>>> On Sat, Feb 06, 2016 at 01:15:42PM +0100, Marek Olšák wrote: >>>>> From: Marek Olšák <marek.ol...@amd.com> >>>>> >>>>> This fixes FP16 conversion instructions for VI, which has 16-bit floats, >>>>> but not SI & CI, which can't disable denorms for those instructions. >>>> >>>> Do you know why this fixes FP16 conversions? What does the OpenGL >>>> spec say about denormal handing? >>> >>> Yes, I know why. The patch explain everything as far as I can see >>> though. What isn't clear? >>> >>> SI & CI: Don't support FP16. FP16 conversions are hardcoded to emit >>> and accept FP16 denormals. >>> VI: Supports FP16. FP16 denormal support is now configurable and >>> affects FP16 conversions as well.(shared setting with FP64). >>> >>> OpenGL doesn't require denormals. Piglit does. I think this is >>> incorrect piglit behavior. >> >> I submitted a public spec bug for this issue: >> >> https://www.khronos.org/bugzilla/show_bug.cgi?id=1460 >> >> I'm investigating whether a similar bug is needed for the SPIR-V >> specification. >> >> I think an argument can be made for either the flush-to-zero or >> non-flush-to-zero behavior in the case of unpackHalf2x16 and (possibly) >> packHalf2x16. The only place in the GLSL 4.50.5 specification that >> mentions subnormal values is section 4.7.1 (Range and Precision). >> >> "The precision of stored single- and double-precision floating-point >> variables is defined by the IEEE 754 standard for 32-bit and 64-bit >> floating-point numbers....Any denormalized value input into a >> shader or potentially generated by any operation in a shader can be >> flushed to 0." >> >> Since there is no half-precision type in desktop GLSL, there is no >> mention of 16-bit subnormal values. As Roland mentioned before, all >> 16-bit subnormal values values are 32-bit normal values. >> >> As I mentioned before, from the point of view of an application >> developer, the flush-to-zero behavior for unpackHalf2x16 is both >> surprising and awful. :) >> >> While I think an argument can be made for either behavior, I also think >> the argument for the non-flush-to-zero behavior is slightly stronger. >> The case for flush-to-zero based on the above spec quotation fails for >> two reasons. First, the "input into [the] shader" is not a subnormal >> number. It is an integer. Second, the "[value] potentially generated >> by [the] operation" is not subnormal in single-precision. > > I don't disagree with that, however OTOH you could make an argument that > such a strong guarantee for packed half floats is inconsistent with > what's required for them elsewhere in GL. In particular half float > texture formats - these are still based on ARB_half_float_pixel. Which > says denormals are optional, infs are optional, NaNs are optional - > albeit that's not any different to ordinary floats...
Thanks for mentioning this. :) The same issue had occurred to me, and I was trying to find some relevant text in the GL spec. I hadn't thought to look in the extension spec. > (And I still have the problem that d3d10 wants trunc behavior instead of > round... fwiw the precedent there in GL is also for r11g11b10 format, > which says round-to-nearest recommended but trunc allowed, and all too > large finite numbers converted to max finite (which is inconsistent with > nearest rounding). The spec is completely silent both within GLSL or GL > how rounding should be done for fp32 to fp16, albeit I don't disagree > round-to-nearest seems the most reasonable.) The GLSL spec isn't silent. Section 4.7.1 explicitly says, "The rounding mode cannot be set and is undefined." > Roland > >> We've already determined that NVIDIA closed-source drivers do not flush >> to zero. I'm curious to know what AMD's closed-source drivers do for >> 16-bit subnormal values supplied to unpackHalf2x16. If they do not >> flush to zero, then you had better believe that applications depend on >> that behavior... and that also means that it doesn't matter very much >> what piglit does or the spec does (or does not) say. This is the sort >> of situation where the spec changes to match application expectations >> and shipping implementations... and Mesa drivers change to follow. This >> isn't even close to the first time through that loop. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
