[Libclc-dev] [PATCH 1/2] amdgcn/fmin: Explicitly check for NaNs

[Jan Vesely via Libclc-dev]

On Wed, 2017-11-15 at 16:16 -0500, Jan Vesely wrote:
> On Wed, 2017-11-15 at 11:43 -0800, Matt Arsenault via Libclc-dev wrote:
> > On 11/15/2017 09:21 AM, Jan Vesely via Libclc-dev wrote:
> > > v_min instruction fails to handle certain NaNs correctly.
> > > 
> > > Signed-off-by: Jan Vesely <jan.vesely at rutgers.edu>
> > > ---
> > > Fixes most of fmin CTS on carrizo. It still fails on denormals, but IMO
> > > that's CTS bug.
> > > EG/NI does not seem to suffer the same problem.
> > 
> > What exact problem are you trying to solve? Do you have an example? NaNs 
> > should work correctly.
> 
> they don't.
> some nan encodings return incorrect value.
> examples from CTS:
> ERROR: fmin: -nan ulp error at {0x1.211a92p-95 (0x10108d49), -nan (0xffa66c5d)}: *0x1.211a92p-95 vs. -nan (0xffe66c5d) at index: 448
> 
> ERROR: fmin: nan ulp error at {nan (0x7fba759e), 0x1.94ea58p-89 (0x134a752c)}: *0x1.94ea58p-89 vs. nan (0x7ffa759e) at index: 450
> 
> ERROR: fmin: nan ulp error at {nan (0x7f9a4655), -0x1.9ed39p-22 (0xb4cf69c8)}: *-0x1.9ed39p-22 vs. nan (0x7fda4655) at index: 617
> 
> ERROR: fmin: nan ulp error at {0x1.303c36p+46 (0x56981e1b), nan (0x7fa7afae)}: *0x1.303c36p+46 vs. nan (0x7fe7afae) at index: 739
> 
> it only shows 4 errors because it used 4 testing threads, there might be more.
> tested on carrizo (fx9800p).

I wrote a small test to check all possible nan encodings [0].
The results are:
Platform is `AMD Radeon R7 Graphics (AMD CARRIZO / DRM 3.13.0 / 4.9.0-ROC-SC, LLVM 4.0.1)' by: AMD version: OpenCL 1.1 Mesa 17.2.4
Wrong1: 8388606/16777216
Platform is `AMD Radeon (TM) R7 M340 (AMD ICELAND / DRM 3.18.0 / 4.11.0-ROC-SC, LLVM 4.0.1)' by: AMD version: OpenCL 1.1 Mesa 17.2.4
Wrong1: 8388606/16777216

also
Platform is `AMD TURKS (DRM 2.50.0 / 4.13.11-200.fc26.x86_64, LLVM 6.0.0)' by: AMD version: OpenCL 1.1 Mesa 17.4.0-devel (git-edd7bd55ed)
Wrong1: 0/16777216

Jan

[0] https://github.com/jvesely/ocl_tests/blob/master/fmin/fmin.cpp

> 
> Jan
> 
> 
> > We do have some issues with denorm flushing 
> > behavior changing on gfx9.
> > _______________________________________________
> > Libclc-dev mailing list
> > Libclc-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/libclc-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/libclc-dev/attachments/20171116/677d6b46/attachment.sig>