Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas
On 24/02/2023 23.52, Adrian Bunk wrote:> $ clang-15 -march=i686 -O2 test_fmod.c -lm -frounding-math && ./a.out > (-ffp-model=strict is a superset of -frounding-math) Very nice finding, unfortunately pocl fails most of its tests (with a seemingly unrelated error) if I enable one of these options for kernel compilation. https://github.com/pocl/pocl/issues/1183 Andreas
Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas
On Thu, Feb 16, 2023 at 11:34:32PM +0100, Andreas Beckmann wrote: >... > On Thu, 16 Feb 2023 21:46:31 + "Rebecca N. Palmer" > wrote: > > The trigger is probably pocl, not clinfo. I don't yet know whether the > > bug is in pocl or libgpuarray. > or llvm-15 > > pocl/sid is built against llvm-15, pocl/testing against llvm-14 > > This also causes a test regression in pyopencl due to numerical differences > (#1030298). This was attempted to be fixed in pyopencl upstream by requiring > the numerical difference to be below some tolerance level instead of > requiring equality, but the numerical delta is too large to hide behind that > ... >... FYI: $ clang-15 -march=i686 -O2 test_fmod.c -lm && ./a.out a=0 b=0.1 c=0 d=0 abserr=0 relerr=0 a=0.1 b=0.1221239 c=0.1 d=0.1 abserr=0 relerr=0 a=0.2 b=0.14424779 c=0.055752218 d=0.055752214 abserr=-3.72529e-09 relerr=-2.58256e-08 a=0.3 b=0.16637169 c=0.13362832 d=0.13362831 abserr=-1.49012e-08 relerr=-8.95655e-08 a=0.4 b=0.18849558 c=0.023008853 d=0.023008848 abserr=-5.58794e-09 relerr=-2.96449e-08 a=0.5 b=0.21061946 c=0.078761071 d=0.078761071 abserr=0 relerr=0 a=0.6 b=0.23274337 c=0.13451329 d=0.13451326 abserr=-2.98023e-08 relerr=-1.28048e-07 FAIL a=0.7 b=0.25486726 c=0.19026548 d=0.19026549 abserr=1.49012e-08 relerr=5.84664e-08 a=0.8 b=0.27699116 c=0.24601769 d=0.24601768 abserr=-1.49012e-08 relerr=-5.37965e-08 a=0.9 b=0.29911503 c=0.0026548803 d=0.002654904 abserr=2.37487e-08 relerr=7.93966e-08 $ clang-15 -march=i686 -O2 test_fmod.c -lm -frounding-math && ./a.out a=0 b=0.1 c=0 d=0 abserr=0 relerr=0 a=0.1 b=0.1221239 c=0.1 d=0.1 abserr=0 relerr=0 a=0.2 b=0.14424779 c=0.055752218 d=0.055752218 abserr=0 relerr=0 a=0.3 b=0.16637169 c=0.13362832 d=0.13362832 abserr=0 relerr=0 a=0.4 b=0.18849558 c=0.023008853 d=0.023008853 abserr=0 relerr=0 a=0.5 b=0.21061946 c=0.078761071 d=0.078761071 abserr=0 relerr=0 a=0.6 b=0.23274337 c=0.13451329 d=0.13451329 abserr=0 relerr=0 a=0.7 b=0.25486726 c=0.19026548 d=0.19026548 abserr=0 relerr=0 a=0.8 b=0.27699116 c=0.24601769 d=0.24601769 abserr=0 relerr=0 a=0.9 b=0.29911503 c=0.0026548803 d=0.0026548803 abserr=0 relerr=0 $ clang-15 -march=i686 -O2 test_fmod.c -lm -ffp-model=strict && ./a.out a=0 b=0.1 c=0 d=0 abserr=0 relerr=0 a=0.1 b=0.1221239 c=0.1 d=0.1 abserr=0 relerr=0 a=0.2 b=0.14424779 c=0.055752218 d=0.055752218 abserr=0 relerr=0 a=0.3 b=0.16637169 c=0.13362832 d=0.13362832 abserr=0 relerr=0 a=0.4 b=0.18849558 c=0.023008853 d=0.023008853 abserr=0 relerr=0 a=0.5 b=0.21061946 c=0.078761071 d=0.078761071 abserr=0 relerr=0 a=0.6 b=0.23274337 c=0.13451329 d=0.13451329 abserr=0 relerr=0 a=0.7 b=0.25486726 c=0.19026548 d=0.19026548 abserr=0 relerr=0 a=0.8 b=0.27699116 c=0.24601769 d=0.24601769 abserr=0 relerr=0 a=0.9 b=0.29911503 c=0.0026548803 d=0.0026548803 abserr=0 relerr=0 $ (-ffp-model=strict is a superset of -frounding-math) > Andreas cu Adrian
Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas
Possibly useful here: gdb disassemble works inside pocl kernels, see #920497 for an example.
Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas
Hi, On 16-02-2023 23:34, Andreas Beckmann wrote: @elbrus: Why does britney try to migrate clinfo together with pocl? Honestly, I don't know. The logic that does that *is* rather greedy as often it helps (but not always). IMO clinfo should be able to migrate on its own without causing new regressions in testing. It does not have any (transitive) dependency on pocl. I have scheduled the job with only clinfo from unstable and the test passed. So I think clinfo can just migrate after the information becomes available. Thanks. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas
Control: forwarded -1 https://github.com/pocl/pocl/issues/1176 @elbrus: Why does britney try to migrate clinfo together with pocl? IMO clinfo should be able to migrate on its own without causing new regressions in testing. It does not have any (transitive) dependency on pocl. On Thu, 16 Feb 2023 21:46:31 + "Rebecca N. Palmer" wrote: The trigger is probably pocl, not clinfo. I don't yet know whether the bug is in pocl or libgpuarray. or llvm-15 pocl/sid is built against llvm-15, pocl/testing against llvm-14 This also causes a test regression in pyopencl due to numerical differences (#1030298). This was attempted to be fixed in pyopencl upstream by requiring the numerical difference to be below some tolerance level instead of requiring equality, but the numerical delta is too large to hide behind that ... I'm currently trying to debug the code generation delta between llvm-14 and llvm-15 ... There could still be a bug in libgpuarray if the failing test is too strict by requiring equality of some floating point computations. (Not checked.) Andreas
Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas
Control: reassign -1 src:pocl,src:libgpuarray Control: found -1 pocl/3.1-3 Control: found -1 libgpuarray/0.7.6-13 Control: retitle -1 libgpuarray: i386 test fail with new pocl The trigger is probably pocl, not clinfo. I don't yet know whether the bug is in pocl or libgpuarray.
Bug#1031414: clinfo breaks libgpuarray autopkgtest on i386: numerical deltas
Source: clinfo, libgpuarray Control: found -1 clinfo/3.0.23.01.25-1 Control: found -1 libgpuarray/0.7.6-13 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of clinfo the autopkgtest of libgpuarray fails in testing when that autopkgtest is run with the binary packages of clinfo from unstable. It passes when run with only packages from testing. In tabular form: passfail clinfo from testing3.0.23.01.25-1 libgpuarrayfrom testing0.7.6-13 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of clinfo to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from clinfo/3.0.23.01.25-1. I.e. due to versioned dependencies or breaks/conflicts. [1] https://qa.debian.org/excuses.php?package=clinfo https://ci.debian.net/data/autopkgtest/testing/i386/libg/libgpuarray/31439784/log.gz === FAILURES === __ test_ielemwise2_ops_mixed ___ def test_ielemwise2_ops_mixed(): for op in ioperators2: for dtype in dtypes_test: for elem in elems: ielemwise2_ops_mixed(op, dtype, (50,), elem) /usr/lib/python3/dist-packages/pygpu/tests/test_elemwise.py:173: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /usr/lib/python3/dist-packages/pygpu/tests/support.py:44: in f func(*args, **kwargs) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ op = , dtype = 'float32', shape = (50,), elem = 0.3 @guard_devsup def ielemwise2_ops_mixed(op, dtype, shape, elem): incr = 0 if op == operator.isub and dtype[0] == 'u': # array elements are smaller than 10 by default, so we avoid underflow incr = 10 c, g = gen_gpuarray(shape, dtype, incr=incr, ctx=context, cls=elemary) try: out_c = op(c, elem) except TypeError: # TODO: currently, we use old Numpy semantic and tolerate more case. # So we can't test that we raise the same error return out_g = op(g, elem) assert out_g is g assert out_c.shape == out_g.shape assert out_c.dtype == out_g.dtype assert numpy.allclose(out_c, numpy.asarray(out_g)) E assert False E+ where False = 0xf3ad35c8>(array([0.16798985, 0.10199559, 0.00094628, 0.284034 , 0.00356799,\n 0.18276209, 0.06017095, 0.12363595, 0.14555043, 0.06383288,\n 0.27849692, 0.23479545, 0.1120947 , 0.03348678, 0.17435497,\n 0.10784233, 0.15038443, 0.08132076, 0.26949704, 0.28150958,\n 0.08847237, 0.07874835, 0.14240652, 0.22457486, 0.02050698,\n 0.24944574, 0.29784787, 0.03708786, 0.23751181, 0.26554942,\n 0.26809436, 0.02403933, 0.23044948, 0.13133025, 0.29589295,\n 0.05166197, 0.07869713, 0.10319626, 0.07735932, 0.241211 ,\n 0.27668405, 0.16557133, 0.26950228, 0.230201 , 0.2993518 ,\n 0.0713675 , 0.02841425, 0.04263723, 0.194592 , 0.2564727 ],\n dtype=float32), array([0.16798979, 0.10199571, 0.00094652, 0.28403443, 0.00356805,\n 0.1827622 , 0.06017077, 0.12363613, 0.14555037, 0.063833 ,\n 0.2784968 , 0.23479551, 0.11209452, 0.03348672, 0.17435497,\n 0.10784221, 0.1503846 , 0.08132076, 0.26949698, 0.28150946,\n 0.08847237, 0.07874823, 0.14240658, 0.22457486, 0.0205071 ,\n 0.24944574, 0.29784793, 0.0370878 , 0.2375117 , 0.26554942,\n 0.26809436, 0.02403933, 0.23044948, 0.13133001, 0.29589337,\n 0.05166197, 0.07869713, 0.10319638, 0.07735932, 0.24121124,\n 0.276684 , 0.16557115, 0.26950234, 0.230201 , 0.29935163,\n 0.07136726, 0.02841425, 0.04263711, 0.19459194, 0.25647253],\n dtype=float32)) E+where = numpy.allclose E+and array([0.16798979, 0.10199571, 0.00094652, 0.28403443, 0.00356805,\n 0.1827622 , 0.06017077, 0.12363613, 0.14555037, 0.063833 ,\n 0.2784968 , 0.23479551, 0.11209452, 0.03348672, 0.17435497,\n 0.10784221, 0.1503846 , 0.08132076, 0.26949698, 0.28150946,\n 0.08847237, 0.07874823, 0.14
