<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Add FP64 support to the i965 shader backends" href="https://bugs.freedesktop.org/show_bug.cgi?id=92760#c72">Comment # 72</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Add FP64 support to the i965 shader backends" href="https://bugs.freedesktop.org/show_bug.cgi?id=92760">bug 92760</a> from <a class="email" href="mailto:jason@jlekstrand.net" title="Jason Ekstrand <jason@jlekstrand.net>"> Jason Ekstrand</a> <pre>(In reply to Iago Toral from <a href="show_bug.cgi?id=92760#c66">comment #66</a>) > Jason, Connor: > > last week Curro spent some time looking at our fp64 branch and testing some > things and we have been discussing some aspects of the hardware in fp64 that > are not all that well documented (or not even documented at all :)) and that > may have some important implications in the implementation, specifically for > the vec4 backend. > > Opinions? Short version: a) The hardware is busted. b) I think Curro knows what he's talking about. :-) Longer version: I see a couple of options here: One is to just scalarize all double stuff. On Ivy Bridge, I think you would also have to double up instructions, one for each half. It's not a great option from the perspective of performance but is perhaps the easiest to implement. The second option is what Curro's suggesting where you try and use the hardware as much as possible and fall back to nasty things only when you have to. Unfortunately, this is going to cause a lot of pain in the generator because suddenly lots of stuff may become align1 at least on IVB. If we want to do option 2, I think we want some sort of lowering pass that runs after all the optimizations and before generation that applies all the nasty work-arounds. Proior to the lowering pass we would treat swizzles and writemasks as something sensible such as actually working on dvec4 components. The lowering pass would turn those into something the hardware can handle and maybe add extra code to resolve swizzles and writemasks that the hardware can't do natively. On Ivy Bridge, the hardware can do almost nothing natively and the pass would be aware of that. It would need to run after all the optimizations because we want optimizations to be able to assume swizzles are sensible so we don't have to implement crazy hardware restrictions at every level. If it's practical, this seems like the best plan. As far as the NIR splitting pass goes: If it's not useful, throw it away! No one will get their feelings hurt. Connor and I were working under the assumption that the hardware was at least mildly sane and, as it turns out, we were wrong.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>