<br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 14, 2018, 9:59 PM Jan Vesely <<a href="mailto:jan.vesely@rutgers.edu">jan.vesely@rutgers.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2018-05-10 at 21:19 -0500, Aaron Watry via Libclc-dev wrote:<br>
> On Thu, May 10, 2018 at 7:02 PM, Jan Vesely <<a href="mailto:jan.vesely@rutgers.edu" target="_blank">jan.vesely@rutgers.edu</a>> wrote:<br>
> > On Thu, 2018-05-10 at 15:43 -0500, Aaron Watry via Libclc-dev wrote:<br>
> > > On Thu, May 10, 2018 at 1:52 PM, Jan Vesely <<a href="mailto:jan.vesely@rutgers.edu" target="_blank">jan.vesely@rutgers.edu</a>> wrote:<br>
> > > > On Thu, 2018-05-10 at 13:43 -0500, Aaron Watry via Libclc-dev wrote:<br>
> > > > > On Thu, May 10, 2018 at 1:16 PM, Jan Vesely <<a href="mailto:jan.vesely@rutgers.edu" target="_blank">jan.vesely@rutgers.edu</a>> wrote:<br>
> > > > > > On Wed, 2018-05-02 at 22:16 -0500, Aaron Watry via Libclc-dev wrote:<br>
> > > > > > > On Wed, 2018-05-02 at 21:51 -0400, Jan Vesely wrote:<br>
> > > > > > > > On Wed, 2018-05-02 at 07:03 -0500, Aaron Watry via Libclc-dev wrote:<br>
> > > > > > > > > Am I being dense or just lucky (device supports denormals?).. This<br>
> > > > > > > > > already passed on my RX580 before I applied your patch.<br>
> > > > > > > > <br>
> > > > > > > > IIRC, the problem is not with denormal support (unless you enabled it<br>
> > > > > > > > explicitly), but that 'indx' variable was computed incorrectly. My<br>
> > > > > > > > guess would be that one of the earlier operations (mad?) improved wrt<br>
> > > > > > > > ULP precision (rootn still failed on my carrizo).<br>
> > > > > > > > Anyway, flushing denormals just hides the issue. it'll probably still<br>
> > > > > > > > fail if run with denormals enabled, but fixing denormal support is a<br>
> > > > > > > > story for another day.<br>
> > > > > > > > <br>
> > > > > > > > > I'm currently rebuilding new newer llvm on my r600 box that<br>
> > > > > > > > > hopefully<br>
> > > > > > > > > won't segfault when running rootn to test there.<br>
> > > > > > > > <br>
> > > > > > > > thanks. It works OK on my turks when math_bruteforce is run in single<br>
> > > > > > > > thread mode.<br>
> > > > > > > <br>
> > > > > > > Oh yeah, the compute memory pool on r600 isn't thread-safe...<br>
> > > > > > > <br>
> > > > > > > Let's just say that the email I sent this morning was while the first<br>
> > > > > > > cup of coffee was still unconsumed, and I had a small child in my lap<br>
> > > > > > > trying to commandeer my mouse. Not a great time for deep thoughts. :)<br>
> > > > > > <br>
> > > > > > Hi,<br>
> > > > > > <br>
> > > > > > any luck running on your r600?<br>
> > > > > <br>
> > > > > Yes, in single-threaded mode. But in my case (HD 6850, BARTS) the<br>
> > > > > rootn test already passed with a max ULP of 1.0 before you patch, and<br>
> > > > > a max ULP of 7.0 after.<br>
> > > > > <br>
> > > > > The tolerance for rootn is <= 16, so both cases passed, but the<br>
> > > > > maximum error seems to have gone up after flushing subnormals.<br>
> > > > > <br>
> > > > > I've been staring at the patch off and on and trying to figure out if<br>
> > > > > it's doing something wrong. Maybe it's just difference in the<br>
> > > > > precision of the hardware we're using.<br>
> > > > > <br>
> > > > > If we really need to, I've also got a cayman-based APU chip and a PCI<br>
> > > > > CEDAR if we want/need to get a few more sample points.<br>
> > > > <br>
> > > > hm, that's interesting. My problem with EG was that it returned NaN. My<br>
> > > > guess would be there is a difference is in LLVM and how it handles<br>
> > > > division/reciprocals.<br>
> > > > Did the other pow (pow{,r,n}) routines also exhibit this behaviour?<br>
> > > <br>
> > > Not sure. I don't believe so (I believe I usually reproduced a CTS<br>
> > > failure for those before confirming the fix), but I'd have to go back<br>
> > > in time with libclc to check.<br>
> > > <br>
> > > For reference, the testing I did with rootn was done with a current<br>
> > > mesa checkout as of earlier today (d07466fe18522cde1) with<br>
> > > LLVM r331343 and libclc r331435 as a base.<br>
> > > <br>
> > > Would you like me to go back and re-check the pow/powr/pown results on<br>
> > > my 6850 from before the denormal flushing changes? I'm re-running all<br>
> > > 3 in their current state right now.<br>
> > <br>
> > Actually my turks setup uses llvm-git. It's weird that you don't see<br>
> > the NaN issues on you cedar.<br>
> <br>
> I have a cedar, but it's currently in another system (An old DEC<br>
> Alpha). The R600-based card I usually test with is the BARTS. The last<br>
> r600 card I have is a 3-core Llano APU (Cayman-derived I believe,<br>
> SUMO2 chip), unless you want to include the chipset-based IGPs on a<br>
> few motherboards I've got.<br>
> <br>
> Just for reference, I went back to the commit immediately before the<br>
> denormal fixes for pow/powr/pown on my BARTS, and all 3 fail wimpy<br>
> mode before the denormal fixes (in single-threaded mode). I haven't<br>
> bothered with a full non-wimpy run.<br>
> <br>
> > I don't think you need to invest much time into this. Given the<br>
> > manpower I think it's preferable to have one version that works across<br>
> > many devices/llvm versions.<br>
> > Improved precision is nice, but probably not something to sweat about.<br>
> > It'd be more interesting to see if the explicit 0 allows the compiler<br>
> > to generate faster code.<br>
> <br>
> Yeah, the test passes within allowed tolerances, and I don't want to<br>
> have multiple versions of the code unless there's a good reason to.<br>
> <br>
> If this lets more chips pass without errors, I'm fine with this going in as-is.<br>
<br>
thanks. May I consider it an acked-by?<br></blockquote></div><div><br></div><div>Yeah. Acked-by, tested-by. Either or both are fine with me.</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jan<br>
<br>
> <br>
> --Aaron<br>
> <br>
> > <br>
> > thanks,<br>
> > Jan<br>
> > <br>
> > > <br>
> > > --Aaron<br>
> > > <br>
> > > > <br>
> > > > Jan<br>
> > > > <br>
> > > > > <br>
> > > > > --Aaron<br>
> > > > > <br>
> > > > > > <br>
> > > > > > Jan<br>
> > > > > > <br>
> > > > > > > <br>
> > > > > > > --Aaron<br>
> > > > > > > <br>
> > > > > > > > <br>
> > > > > > > > Jan<br>
> > > > > > > > <br>
> > > > > > > > > <br>
> > > > > > > > > --Aaron<br>
> > > > > > > > > <br>
> > > > > > > > > On Mon, Apr 30, 2018 at 1:05 PM, Jan Vesely via Libclc-dev<br>
> > > > > > > > > <<a href="mailto:libclc-dev@lists.llvm.org" target="_blank">libclc-dev@lists.llvm.org</a>> wrote:<br>
> > > > > > > > > > On Tue, 2018-04-24 at 12:31 -0400, Jan Vesely wrote:<br>
> > > > > > > > > > > It's OK to either flush to 0 or return denormal result if the<br>
> > > > > > > > > > > device<br>
> > > > > > > > > > > does not support denormals. See sec 7.2 and 7.5.3 of OCL specs<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > v2: Use 0.0f explicitly intead of relying on GPU to flush it.<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > Fixes CTS on carrizo and turks<br>
> > > > > > > > > > > Signed-off-by: Jan Vesely <<a href="mailto:jan.vesely@rutgers.edu" target="_blank">jan.vesely@rutgers.edu</a>><br>
> > > > > > > > > > > ---<br>
> > > > > > > > > > > This removes the need for the second patch<br>
> > > > > > > > > > > generic/lib/math/<a href="http://clc_rootn.cl" rel="noreferrer" target="_blank">clc_rootn.cl</a> | 11 +----------<br>
> > > > > > > > > > > 1 file changed, 1 insertion(+), 10 deletions(-)<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > diff --git a/generic/lib/math/<a href="http://clc_rootn.cl" rel="noreferrer" target="_blank">clc_rootn.cl</a><br>
> > > > > > > > > > > b/generic/lib/math/<a href="http://clc_rootn.cl" rel="noreferrer" target="_blank">clc_rootn.cl</a><br>
> > > > > > > > > > > index d7ee185..0a2c98d 100644<br>
> > > > > > > > > > > --- a/generic/lib/math/<a href="http://clc_rootn.cl" rel="noreferrer" target="_blank">clc_rootn.cl</a><br>
> > > > > > > > > > > +++ b/generic/lib/math/<a href="http://clc_rootn.cl" rel="noreferrer" target="_blank">clc_rootn.cl</a><br>
> > > > > > > > > > > @@ -170,16 +170,7 @@ _CLC_DEF _CLC_OVERLOAD float<br>
> > > > > > > > > > > __clc_rootn(float x, int ny)<br>
> > > > > > > > > > > tv = USE_TABLE(exp_tbl_ep, j);<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > float expylogx = mad(tv.s0, poly, mad(tv.s1, poly, tv.s1))<br>
> > > > > > > > > > > + tv.s0;<br>
> > > > > > > > > > > - float sexpylogx;<br>
> > > > > > > > > > > - if (!__clc_fp32_subnormals_supported()) {<br>
> > > > > > > > > > > - int explg = ((as_uint(expylogx) & EXPBITS_SP32 >><br>
> > > > > > > > > > > 23) - 127);<br>
> > > > > > > > > > > - m = (23-(m + 149)) == 0 ? 1: m;<br>
> > > > > > > > > > > - uint mantissa = ((as_uint(expylogx) &<br>
> > > > > > > > > > > MANTBITS_SP32)|IMPBIT_SP32) >> (23-(m + 149));<br>
> > > > > > > > > > > - sexpylogx = as_float(mantissa);<br>
> > > > > > > > > > > - } else {<br>
> > > > > > > > > > > - sexpylogx = expylogx * as_float(0x1 << (m +<br>
> > > > > > > > > > > 149));<br>
> > > > > > > > > > > - }<br>
> > > > > > > > > > > -<br>
> > > > > > > > > > > + float sexpylogx = __clc_fp32_subnormals_supported() ?<br>
> > > > > > > > > > > expylogx * as_float(0x1 << (m + 149)) : 0.0f;<br>
> > > > > > > > > > > <br>
> > > > > > > > > > > float texpylogx = as_float(as_int(expylogx) + m2);<br>
> > > > > > > > > > > expylogx = m < -125 ? sexpylogx : texpylogx;<br>
> > > > > > > > > > <br>
> > > > > > > > > > ping.<br>
> > > > > > > > > > _______________________________________________<br>
> > > > > > > > > > Libclc-dev mailing list<br>
> > > > > > > > > > <a href="mailto:Libclc-dev@lists.llvm.org" target="_blank">Libclc-dev@lists.llvm.org</a><br>
> > > > > > > > > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev</a><br>
> > > > > > > > > > <br>
> > > > > > > > > <br>
> > > > > > > > > _______________________________________________<br>
> > > > > > > > > Libclc-dev mailing list<br>
> > > > > > > > > <a href="mailto:Libclc-dev@lists.llvm.org" target="_blank">Libclc-dev@lists.llvm.org</a><br>
> > > > > > > > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev</a><br>
> > > > > > > > <br>
> > > > > > > > <br>
> > > > > > > <br>
> > > > > > > _______________________________________________<br>
> > > > > > > Libclc-dev mailing list<br>
> > > > > > > <a href="mailto:Libclc-dev@lists.llvm.org" target="_blank">Libclc-dev@lists.llvm.org</a><br>
> > > > > > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev</a><br>
> > > > > <br>
> > > > > _______________________________________________<br>
> > > > > Libclc-dev mailing list<br>
> > > > > <a href="mailto:Libclc-dev@lists.llvm.org" target="_blank">Libclc-dev@lists.llvm.org</a><br>
> > > > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev</a><br>
> > > <br>
> > > _______________________________________________<br>
> > > Libclc-dev mailing list<br>
> > > <a href="mailto:Libclc-dev@lists.llvm.org" target="_blank">Libclc-dev@lists.llvm.org</a><br>
> > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev</a><br>
> <br>
> _______________________________________________<br>
> Libclc-dev mailing list<br>
> <a href="mailto:Libclc-dev@lists.llvm.org" target="_blank">Libclc-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev</a><br>
<br>
-- <br>
Jan Vesely <<a href="mailto:jan.vesely@rutgers.edu" target="_blank">jan.vesely@rutgers.edu</a>></blockquote></div>