On Sun, Jan 3, 2016 at 7:51 PM, Roland Scheidegger <srol...@vmware.com> wrote: > Am 03.01.2016 um 21:32 schrieb Ilia Mirkin: >> On Sun, Jan 3, 2016 at 2:15 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> On Sun, Jan 3, 2016 at 2:08 PM, Roland Scheidegger <srol...@vmware.com> >>> wrote: >>>>>> For the series (with the first point addressed either way,though a tgsi >>>>>> exec implementation which should be trivial wouldn't hurt neither) >>>>>> Reviewed-by: Roland Scheidegger <srol...@vmware.com> >>>>> >>>>> Thanks! I'll do a patch for that shortly (tgsi_exec). Unfortunately I >>>>> won't be able to enable the cap since it will still use gallivm by >>>>> default for vertices. I have a gallivm implementation as well, but it >>>>> hits asserts on LLVM 3.5. I'm pretty sure I tested it at one point or >>>>> another, but it must have been on another box with a more recent LLVM. >>>> >>>> Ah right. f16 conversion is pretty annoying indeed, though I'd hope the >>>> helpers for that should work. In any case, I only really suggested that >>>> because I'd thought it would be trivial, so if it's not I don't consider >>>> that important... >>> >>> I'll send it out as a separate series, including my (semi?) broken >>> gallivm impl and leave it to you to fix it if you care, or ignore if >>> you don't. (I already have it, so might as well...) I understand >>> neither how LLVM works, nor how gallivm uses LLVM, which isn't a great >>> combination :) >> >> And of course the piglits expect out-of-bounds numbers to be >> represented as infinities, instead of the clamped value > > This is, imho, a bug, they should allow both. Because round-towards-zero > when converting is allowed by GL when converting floats to half, albeit > round-to-nearest-even is preferred. And the former gets you the clamped > values. > >> which is what util_float_to_half does :( > Yep. The reason both the util and gallivm code do round-towards zero is > that for such conversions GL allows both, but d3d10 is deeply unhappy if > you do round-toward-nearest-even (for float to float conversions), at > least for the clamp vs. infinite issue. As per the data conversion > rules: > https://msdn.microsoft.com/en-us/library/windows/desktop/dd607323%28v=vs.85%29.aspx > Albeit there's no specific half float conversion instructions in d3d10 > (but in d3d11), render target conversions etc. must honor these rules too. > I suspect most hw can do both without too much fuzz (x86 f16c certainly > can).
Take it up with people who aren't me :) http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/lower_packing_builtins.cpp#n990 FWIW the f32 -> f16 opcode this maps to on nvc0 has the same behaviour. Now it also has rounding mode flags which I don't set and perhaps one of them would yield the behaviour that you're talking about, but I don't know offhand how to get it. Curiously from the PTX ISA docs: "Conversions to floating-point that are beyond the range of floating-point numbers are represented with the maximum floating-point value (IEEE 754 Inf for f32 and f64, and ~131,000 for f16)." If you get the piglit tests changed, I guess I'll poke around. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
