<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#c63">Comment # 63</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:itoral@igalia.com" title="Iago Toral <itoral@igalia.com>"> Iago Toral</a> <pre>(In reply to Jason Ekstrand from <a href="show_bug.cgi?id=92760#c61">comment #61</a>) > (In reply to Iago Toral from <a href="show_bug.cgi?id=92760#c59">comment #59</a>) (...) > > There are still a couple of things that we need to confirm so we can squash > > or remove a few patches in the series: > > > > 1. We need to make a decision about d2b. We discussed in the list that f2b > > does not need to handle denorms and neither does NVIDIA. On the other hand, > > NVIDIA does handle d2b with denorms (that is, it returns true for them). > > Since doubles are more about precission than performance this could make > > sense for us too. If we want this behavior I have a patch for this in the > > series, following a similar approach to the one I sento to the list for f2b, > > (I should get rid of the resolve_source_modifiers() for gen8 as Jason > > mentioned for the f2b case): > > > > <a href="https://github.com/Igalia/mesa/commit/">https://github.com/Igalia/mesa/commit/</a> > > df6c1d940be455d0e40d9eee2cb0e8987e4baa16 > > I think the spec allows for a lot of wiggle room. With doubles, it may be > easier to implement with bitwise operations like you did in that f2b patch. > Apps shouldn't count on any particular behaviour there other than 0.0 -> > false and obviously non-zero -> true. Any app that counts on the behaviour > of d2b on denorms is going to be broken. If we want the easiest implementation it is actually the one that does not handle denorms, since that is just the CMP plus a swizzled MOV to generate a 32-bit result. The bitwise implementation requires and AND (to remove the sign) and OR of both 32-bit chunks in the DF (to generate a 32-bit result we can compare with 0) and a CMP to generate the boolean result. So, I'll go with the CMP + MOV solution unless you prefer otherwise. (...) > > Also, as soon as we get sized types in NIR we are going to break drivers > > that don't support sized types (freedreno/vc4). I suppose we should ping > > Eric and Rob and point them at our branch so they can have some time to fix > > their drivers accordingly. We did fix some obvious things for them, but they > > should run piglit and probably fix some more stuff. > > That should happen sooner rather than later. > > > I suppose we could try to break the series into smaller chunks that make > > sense to review individually. Initially I was thinking that we might review > > the NIR stuff before the i965 bits... maybe that's a reasonable way to start > > with this, including the minimum i965 stuff required to not break non-double > > things. > > I think the thing to do there would be to break at least one chunk off. > Namely, the bare minimum NIR and i965 changes required to support the new > sized types. That will all have to be squashed into a single commit along > with the vc4 and freedreno changes. We should get that out ASAP so that Rob > and Eric have a chance to fix their drivers so we aren't waiting on them > before we can start landing the rest of it. Sounds good to me, we will start preparing that and ping Eric and Rob. We'll send the result for review as soon as it is done. And thanks for the quick reply, as always! :) > Beyond that, I don't really care how it's split up. The NIR pass for doing > double lowering can be it's own thing. I guess fs and vec4 could be > separate. I'll leave it up to you how you want to do that. It's the same > set of patches at the end of the day.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>