On Wed, Jan 13, 2016 at 2:14 PM, Matt Turner <matts...@gmail.com> wrote:
> On Wed, Jan 13, 2016 at 1:46 PM, Jason Ekstrand <ja...@jlekstrand.net> > wrote: > > On Wed, Jan 13, 2016 at 2:01 AM, Ian Romanick <i...@freedesktop.org> > wrote: > >> On 01/12/2016 05:41 PM, Matt Turner wrote: > >> > Section 8.3.2 of the OpenCL C 2.0 spec is also relevant, but doesn't > >> > touch directly on the issue at hand. > >> > > >> > I'm worried that what is specified is not implementable via a round > >> > trip through half-precision, because it's not the behavior other > >> > languages implement. > >> > > >> > If I had to guess, given the table in the IVB PRM and section 8.3.2, > >> > out-of-range single-precision floats are converted to the > >> > half-precision value with the largest magnitude. > >> > >> You are correct, we should test it to be sure what the hardware really > >> does. This is not intended to be a performance operation. If we need to > >> use a different, more expensive expansion to meet the requirements, we > >> shouldn't lose any sleep over it. > > > > > > I haven't looked at it in bit-for-bit detail, but I I did run it through > a > > set of tests which explicitly hits denorms and the out-of-bounds cases in > > both directions. The tests seem to indicate that the hardware does what > the > > opcode claims. > > I checked out the tests you mention, and none of the cases touch on > what I'm saying (and this has nothing to do with denormal values). Let > me explain again. > Right. Thanks for looking at it. I guess it only checks the explicit infinity case. > The largest representable value in half-precision is > > 65504 == 2.0**15 * (1.0 + 1023.0 / 2.0**10) > > and the distance between representable integers at this range is 32. > Converting 65505.0f through 65519.0f (i.e., one less than half the > interval more than the largest representable value) to half-precision > should round to 65504.0. 65520.0f and larger should round to infinity. > > This is what piglit tests > (generated_tests/gen_builtin_packing_tests.py) and since we pass those > tests I believe this is what the hardware does. > > This is, unfortunately, *not* what the documentation you've cited > says. I expect that that's an oversight more than intentional > behavior. Maybe tomorrow we can figure out how to submit changes to > the spec and test suite? > Yeah, we can look at that tomorrow. The objective of the opcode is to get the behavior that Ian mentioned where if you sprinkle enough of them in, you can emulate half-float precision. What happens if you do FLOAT_MAX + FLOAT_MAX? Maybe infinity is what's wanted. If that's the case, then we'll have to do some sort of absolute value range-check. It doesn't have to be efficient. --Jason
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
