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). Roland _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev