You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(25) |
Nov
(11) |
Dec
(36) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
(30) |
Feb
(4) |
Mar
(4) |
Apr
(7) |
May
(5) |
Jun
(31) |
Jul
(6) |
Aug
(19) |
Sep
(38) |
Oct
(30) |
Nov
(22) |
Dec
(19) |
2013 |
Jan
(55) |
Feb
(39) |
Mar
(77) |
Apr
(10) |
May
(83) |
Jun
(52) |
Jul
(86) |
Aug
(61) |
Sep
(29) |
Oct
(9) |
Nov
(38) |
Dec
(22) |
2014 |
Jan
(14) |
Feb
(29) |
Mar
(4) |
Apr
(19) |
May
(3) |
Jun
(27) |
Jul
(6) |
Aug
(5) |
Sep
(3) |
Oct
(48) |
Nov
|
Dec
(5) |
2015 |
Jan
(8) |
Feb
(2) |
Mar
(8) |
Apr
(16) |
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(13) |
Nov
(5) |
Dec
(2) |
2016 |
Jan
(26) |
Feb
(6) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
|
Jul
|
Aug
(11) |
Sep
(3) |
Oct
(5) |
Nov
(14) |
Dec
(2) |
2017 |
Jan
(16) |
Feb
(4) |
Mar
(11) |
Apr
(4) |
May
(5) |
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(6) |
Oct
|
Nov
(10) |
Dec
(6) |
2018 |
Jan
|
Feb
(21) |
Mar
(11) |
Apr
(3) |
May
(2) |
Jun
(8) |
Jul
|
Aug
(13) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(11) |
2019 |
Jan
|
Feb
(5) |
Mar
(10) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(4) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(4) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(11) |
Jun
(1) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(1) |
2023 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Michal B. <Fra...@ru...> - 2018-06-03 17:55:45
|
Hi, > I am a bit at a loss right now. Does anybody have any other ideas? It > would be good to be able to run the kernel > with full debug symbols so that valgrind or gdb can give some more Pocl currently compiles the kernels without debuginfo, and while adding a debug option is quite easy, Pocl does a lot of transformation on the compiled bitcode, so making sure the debuginfo still makes sense after all transforms, could be quite a bit of work. Can you try disassembling the kernel crash ? gdb commands are "set disassembly-flavor intel" and "disassemble". Find the instruction that's crashing (has a "=>" next to it) and print the contents of registers ("info registers"). Then pastebin the all this somewhere. Regards, -- mb |
From: Timo B. <tim...@gm...> - 2018-06-02 23:44:07
|
Hi, I did not know Oclgrind I have managed to compile it now. But oclgrind segfaults with the kernel as well without giving any kind of debug message (interactive stepping is not possible either, it just segfaults). I checked the private memory size, which is more than fine. I also tried valgrind. But the only thing I see is that it crashes in the kernel launcher, but not where. I am a bit at a loss right now. Does anybody have any other ideas? It would be good to be able to run the kernel with full debug symbols so that valgrind or gdb can give some more useful output. Also, it is very strange that the Intel CPU, Nvidia GPU and AMD Gpu Opencl drivers do not pick up on an error. Only the LLVM based implementations in POCL and Oclgrind crash. Best wishes Timo On Wed, 30 May 2018 at 15:16, Andreas Kloeckner <li...@in...> wrote: > Timo Betcke <tim...@gm...> writes: > > I am observing a crash with one of my OpenCL kernels on POCL in double > > precison (single precision works fine). I don't observe this crash on > other > > OpenCL implementations and printf debugging does not really show what is > > going on. > > > > I am running my kernels through PyOpenCL. I tried to debug with gdb > --args > > python test_p1.py. > > But while POCL debug symbols are shown, they are not shown for the > kernel. > > The only message I get is that the crash is in > > _pocl_launcher_evaluate_regular. The full gdb output is shown below up to > > the first function that has debug symbols available. > > > > Any hint would be great. > > Did you try oclgrind on that kernel? (Just a thought) > > Andreas > -- Dr Timo Betcke Reader in Mathematics University College London Department of Mathematics E-Mail: t.b...@uc... Tel.: +44 (0) 20-3108-4068 Fax.: +44 (0) 20-7383-5519 |
From: Andreas K. <li...@in...> - 2018-05-30 13:42:52
|
Timo Betcke <tim...@gm...> writes: > I am observing a crash with one of my OpenCL kernels on POCL in double > precison (single precision works fine). I don't observe this crash on other > OpenCL implementations and printf debugging does not really show what is > going on. > > I am running my kernels through PyOpenCL. I tried to debug with gdb --args > python test_p1.py. > But while POCL debug symbols are shown, they are not shown for the kernel. > The only message I get is that the crash is in > _pocl_launcher_evaluate_regular. The full gdb output is shown below up to > the first function that has debug symbols available. > > Any hint would be great. Did you try oclgrind on that kernel? (Just a thought) Andreas |
From: Timo B. <tim...@gm...> - 2018-05-30 12:55:37
|
Hi, I am observing a crash with one of my OpenCL kernels on POCL in double precison (single precision works fine). I don't observe this crash on other OpenCL implementations and printf debugging does not really show what is going on. I am running my kernels through PyOpenCL. I tried to debug with gdb --args python test_p1.py. But while POCL debug symbols are shown, they are not shown for the kernel. The only message I get is that the crash is in _pocl_launcher_evaluate_regular. The full gdb output is shown below up to the first function that has debug symbols available. Any hint would be great. Best wishes Timo ----------------------------------- Starting program: /home/betcke/.conda/envs/opencl/bin/python ./test_p1.py [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Missing separate debuginfo for /home/betcke/.conda/envs/opencl/lib/python3.6/site-packages/numpy/../../../libiomp5.so Missing separate debuginfo for /lib64/libOpenCL.so.1 Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/18/de8b5046adcfe0be9627f9cdab1812fe715d89.debug [New Thread 0x7fffd6dca700 (LWP 11143)] [New Thread 0x7fffd65c9700 (LWP 11144)] [New Thread 0x7fffd5dc8700 (LWP 11145)] [New Thread 0x7fffd55c7700 (LWP 11146)] [Thread 0x7fffd55c7700 (LWP 11146) exited] [Thread 0x7fffd5dc8700 (LWP 11145) exited] [Thread 0x7fffd65c9700 (LWP 11144) exited] [Thread 0x7fffd6dca700 (LWP 11143) exited] X server found. dri2 connection failed! [New Thread 0x7fffd55c7700 (LWP 11147)] Default device: pthread-Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz Detaching after fork from child process 11148. Detaching after fork from child process 11150. Thread 6 "python" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd55c7700 (LWP 11147)] 0x00007fffae8f6865 in _pocl_launcher_evaluate_regular () from /home/betcke/.cache/pocl/kcache/GG/BJMJJGGNAPAMOJGKFMNAAIEDJNENJNLGAPNEO/evaluate_regular/0-0-0/evaluate_regular.so (gdb) up #1 0x00007fffae8f6cc9 in _pocl_launcher_evaluate_regular_workgroup () from /home/betcke/.cache/pocl/kcache/GG/BJMJJGGNAPAMOJGKFMNAAIEDJNENJNLGAPNEO/evaluate_regular/0-0-0/evaluate_regular.so (gdb) up #2 0x00007fffd6f8694d in work_group_scheduler (thread_data=0xc4d2c0, k=0x7fffc0001a80) at /usr/src/debug/pocl-1.1-2.fc28.x86_64/lib/CL/devices/pthread/pthread_scheduler.c:407 407 k->workgroup (arguments, &pc); (gdb) ---------------------------------- -- Dr Timo Betcke Reader in Mathematics University College London Department of Mathematics E-Mail: t.b...@uc... Tel.: +44 (0) 20-3108-4068 Fax.: +44 (0) 20-7383-5519 |
From: O. H. <oha...@wa...> - 2018-04-11 09:30:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Wed, 11 Apr 2018 09:41:36 +0200 "O. Hartmann" <oha...@wa...> schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Am Tue, 13 Mar 2018 08:53:04 +0100 > Michal Babej <Fra...@ru...> schrieb: > > > I'm sorry having such a delay (time ...). > > > On Sun, 11 Mar 2018 11:04:45 +0100 > > "O. Hartmann" <o.h...@wa...> wrote: > > > > > The script devel-envs.sh is a Bourne shell script, so I guess > > > "sourcing" it like c shell scripts isn't appropriate here, it fails, > > > executed from POCL's BUILD directory: > > > > Ah sorry, forgot about FreeBSD's C shell. That script merely sets up > > 2-3 env variables to run pocl from build directory. > > > > > Unable to find symbol pthread_mutexattr_setkind_np version (null). > > > Aborting. Abort > > > > I'm afraid I have never seen this bug. The closest thing i see in pocl > > source is > > I think this problem is a well known problem with LLVM - and it pops up in new clothings > and at an unexpected place now. > > According to this bug > > http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html > > it seems, that when multiple LLVM backed platforms are present, the error occurs. > > Prior to the checks, with POCL 1.0 or POCL 0.14, the problems occured when trying to run > a pocl program with ocl-icd and other OpenCL platforms present on the system, like > clover or Intel's beignet. > > > > > PTHREAD_CHECK(pthread_mutexattr_settype(&mattr, > > PTHREAD_MUTEX_ERRORCHECK)); > > > > ... but this is in pocl-hsa.c and you're not building HSA-enabled pocl. > > > > > > -- mb > > Kind regards, > > Oliver > The problem I reported and the source of the error PTHREAD_CHECK() is a missing linking against pthread in our devel/ocl-icd port. Fixing that leaves me then with the well known bug reported here: https://github.com/pocl/pocl/issues/474 and, as mentioned above, here http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html Regards, Oliver - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWs3VrQAKCRDS528fyFhY lK9LAf0Swv3er2r3EI8Wv0EerjsVvEvBfkVLqo83shuZhekbEOD60/mw47B9TSer m6t+oGUDAHrnWC/S72n/0ib80iAuAf9Vbow/J8Thu2bKZDv1oqf46RmHPCYAbuxv oVMSMvh3zepEJK2+Rp9/Oq6u9BzCl3uNGno1ejm0/bGLD20tPaPU =dcsI -----END PGP SIGNATURE----- |
From: O. H. <o.h...@wa...> - 2018-04-11 08:53:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Wed, 11 Apr 2018 09:41:36 +0200 "O. Hartmann" <oha...@wa...> schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Am Tue, 13 Mar 2018 08:53:04 +0100 > Michal Babej <Fra...@ru...> schrieb: > > > I'm sorry having such a delay (time ...). > > > On Sun, 11 Mar 2018 11:04:45 +0100 > > "O. Hartmann" <o.h...@wa...> wrote: > > > > > The script devel-envs.sh is a Bourne shell script, so I guess > > > "sourcing" it like c shell scripts isn't appropriate here, it fails, > > > executed from POCL's BUILD directory: > > > > Ah sorry, forgot about FreeBSD's C shell. That script merely sets up > > 2-3 env variables to run pocl from build directory. > > > > > Unable to find symbol pthread_mutexattr_setkind_np version (null). > > > Aborting. Abort > > > > I'm afraid I have never seen this bug. The closest thing i see in pocl > > source is > > I think this problem is a well known problem with LLVM - and it pops up in new clothings > and at an unexpected place now. > > According to this bug > > http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html > > it seems, that when multiple LLVM backed platforms are present, the error occurs. > > Prior to the checks, with POCL 1.0 or POCL 0.14, the problems occured when trying to run > a pocl program with ocl-icd and other OpenCL platforms present on the system, like > clover or Intel's beignet. > > > > > PTHREAD_CHECK(pthread_mutexattr_settype(&mattr, > > PTHREAD_MUTEX_ERRORCHECK)); > > > > ... but this is in pocl-hsa.c and you're not building HSA-enabled pocl. > > > > > > -- mb > > Kind regards, > > Oliver [...] Sorry, there was an issue with our port devel/ocl-icd, the linking against pthread lib was missing. Now I receive the issue I see since a long time and I was refering to in my last email (LLVM bug, not fixed): [...] Device open failed, aborting... : CommandLine Error: Option 'enable-value-profiling' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Nothing to output ! - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWs3M9AAKCRDS528fyFhY lCLHAgCJYBpXPukDj5Yyhj5yCsIKfvRhkN5BzWEznD1GK5oAqzZkV3GGHEC3I1Ba 4x/spy5tXo0Pc5I4uAhCcD6KG+YTAfwNpq1EpCeKapK35KFc2Me0AbYJX/KvxpQf RWOWNG7A9oOl5MjuybMhx20mzDUnQaQBHgYZvIAcOgqyJeYItt6r =oxbS -----END PGP SIGNATURE----- |
From: O. H. <oha...@wa...> - 2018-04-11 07:55:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Tue, 13 Mar 2018 08:53:04 +0100 Michal Babej <Fra...@ru...> schrieb: I'm sorry having such a delay (time ...). > On Sun, 11 Mar 2018 11:04:45 +0100 > "O. Hartmann" <o.h...@wa...> wrote: > > > The script devel-envs.sh is a Bourne shell script, so I guess > > "sourcing" it like c shell scripts isn't appropriate here, it fails, > > executed from POCL's BUILD directory: > > Ah sorry, forgot about FreeBSD's C shell. That script merely sets up > 2-3 env variables to run pocl from build directory. > > > Unable to find symbol pthread_mutexattr_setkind_np version (null). > > Aborting. Abort > > I'm afraid I have never seen this bug. The closest thing i see in pocl > source is I think this problem is a well known problem with LLVM - and it pops up in new clothings and at an unexpected place now. According to this bug http://lists.llvm.org/pipermail/llvm-bugs/2016-October/051237.html it seems, that when multiple LLVM backed platforms are present, the error occurs. Prior to the checks, with POCL 1.0 or POCL 0.14, the problems occured when trying to run a pocl program with ocl-icd and other OpenCL platforms present on the system, like clover or Intel's beignet. > > PTHREAD_CHECK(pthread_mutexattr_settype(&mattr, > PTHREAD_MUTEX_ERRORCHECK)); > > ... but this is in pocl-hsa.c and you're not building HSA-enabled pocl. > > > -- mb Kind regards, Oliver - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -----BEGIN PGP SIGNATURE----- iLQEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWs28TAAKCRDS528fyFhY lIlzAfdTXoTmHdlk57227PHb1+gxFg8g8J+hCfAqjX+k8pM2n+Lp7ZghaAfAKuR6 vhdvdTaZBUb/c0gGjT51GMop1OAB/1leN+f4WNV+2xfo7YPtTEzp1vN0onoa4HOb cjvndCe3Yi6+WTtAA3cuQlLorTFIwT63DcxBqEqzukU0zrgOTN8= =yq4A -----END PGP SIGNATURE----- |
From: O. H. <o.h...@wa...> - 2018-03-11 10:05:30
|
Am Sat, 10 Mar 2018 11:17:36 +0100 Michal Babej <Fra...@ru...> schrieb: > Hi, > > > Trying to prepare an adaption of POCL 1.1 to FreeBSD (CURRENT at the > > moment), using LLVM/CLANG 5, compilation runs well, but the final > > tests fail due to the initial error in pocl_version_check, like > > > > pocl_version_check ..................................................................***Failed > > > Does anybody else face this error? > > > > That test does one thing: it loads OpenCL and checks that the platform > version matches "OpenCL 1.2 pocl X.Y". Two common ways this could fail > are 1) you have another OpenCL platform installed, or 2) loading > libpocl.so fails (usually due to linking problems). > > If you have ocl-icd installed as ICD loader, then an easy check is: > > source <path-to-pocl-source-dir>/tools/scripts/devel-envs.sh > clinfo The script devel-envs.sh is a Bourne shell script, so I guess "sourcing" it like c shell scripts isn't appropriate here, it fails, executed from POCL's BUILD directory: source ./tools/scripts/devel-envs.sh libs_subdir=.: Command not found. export: Command not found. export: Command not found. export: Command not found. export: Command not found. [...] Executing # (sh ./tools/scripts/devel-envs.sh && clinfo) gives me Unable to find symbol pthread_mutexattr_setkind_np version (null). Aborting. Abort This is something I see lately very often due to some weirdness in registering ICDs. This is with compiling pocl with LLVM 6. > > from pocl's BUILD directory. If it prints 0 platforms then likely you > have linking issues. Or you could build pocl with -DENABLE_ICD=0 and > it'll fail linking the tests, if there are any problems. Installed (on my test box) is ocl-icd 2.2.12, on another box there is the regular ocl-icd package/port devel/ocl-icd in the FreeBSD ports tree, which is version 2.2.11. this just for the record if it matters. > > Cheers, > -- mb > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). |
From: Michal B. <Fra...@ru...> - 2018-03-11 09:16:00
|
Hi, > fdatasync() doesn't seem to exist. .. and yet, CMake finds it: -- Performing Test HAVE_FDATASYNC -- Performing Test HAVE_FDATASYNC - Success so either the CMake test gets it wrong, or it exists and there is some missing include somewhere. Plus there are more problems: /Users/travis/miniconda3/conda-bld/pocl_1520730988784/work/pocl-1.1/lib/CL/pocl_timing.c:114:10: note: forward declaration of 'struct tm' /Users/travis/miniconda3/conda-bld/pocl_1520730988784/work/pocl-1.1/lib/CL/pocl_timing.c:136:3: warning: implicit declaration of function 'gmtime_r' is invalid in C99 [-Wimplicit-function-declaration] > On a related note, I recall one of you commenting that you might be > interested in a macOS build slave. I might be able to help with There's an open PR for it by Jeff Hammond, with a Travis build bot setup, so i think your Mac Mini will *probably* not be required. What we need more than buildbots is maintainers (or at least someone who occasionally makes it work on Mac). Cheers, -- mb |
From: Andreas K. <li...@in...> - 2018-03-11 04:16:56
|
Andreas Kloeckner <li...@in...> writes: > Here's the next macOS build failure on macOS on POCL 1.1: > > https://travis-ci.org/conda-forge/pocl-feedstock/builds/351854461 > > fdatasync() doesn't seem to exist. > > On a related note, I recall one of you commenting that you might be > interested in a macOS build slave. I might be able to help with > that. It's a Sandy Bridge Mac Mini with 8 GiB RAM that's sitting in a > lab here. It's not hugely powerful, but it should be able get the job > done. On yet another related note, you may want to upstream this patch: https://github.com/conda-forge/pocl-feedstock/pull/15/commits/20e2a4a3137e57470b965e2ab9be9cd4637cf020 (Credit goes to Isuru Fernando, who figured out what the problem was and created the patch.) Andreas |
From: Andreas K. <li...@in...> - 2018-03-11 01:52:09
|
Hi all, Here's the next macOS build failure on macOS on POCL 1.1: https://travis-ci.org/conda-forge/pocl-feedstock/builds/351854461 fdatasync() doesn't seem to exist. On a related note, I recall one of you commenting that you might be interested in a macOS build slave. I might be able to help with that. It's a Sandy Bridge Mac Mini with 8 GiB RAM that's sitting in a lab here. It's not hugely powerful, but it should be able get the job done. Andreas |
From: Andreas K. <li...@in...> - 2018-03-10 18:52:16
|
Michal Babej <Fra...@ru...> writes: > CMake Error > at /Users/travis/miniconda3/conda-bld/pocl_1520641026167/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/share/cmake-3.10/Modules/TestBigEndian.cmake:49 > (message): no suitable type found Call Stack (most recent call first): > CMakeLists.txt:1137 (TEST_BIG_ENDIAN) > > According to a quick google, it's a CMake problem. Did you try building > with Clang as system compiler ? > > cmake -DCMAKE_C_COMPILER=<path-to-clang> > -DCMAKE_CXX_COMPILER=<path-to-clang++> <path-to-pocl-sources> Thanks for the tip! I tried that, it hasn't helped: https://travis-ci.org/conda-forge/pocl-feedstock/builds/351767014 Andreas |
From: Michal B. <Fra...@ru...> - 2018-03-10 10:27:36
|
Hi, CMake Error at /Users/travis/miniconda3/conda-bld/pocl_1520641026167/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/share/cmake-3.10/Modules/TestBigEndian.cmake:49 (message): no suitable type found Call Stack (most recent call first): CMakeLists.txt:1137 (TEST_BIG_ENDIAN) According to a quick google, it's a CMake problem. Did you try building with Clang as system compiler ? cmake -DCMAKE_C_COMPILER=<path-to-clang> -DCMAKE_CXX_COMPILER=<path-to-clang++> <path-to-pocl-sources> -- mb |
From: Michal B. <Fra...@ru...> - 2018-03-10 10:17:59
|
Hi, > Trying to prepare an adaption of POCL 1.1 to FreeBSD (CURRENT at the > moment), using LLVM/CLANG 5, compilation runs well, but the final > tests fail due to the initial error in pocl_version_check, like > > pocl_version_check ..................................................................***Failed > Does anybody else face this error? > That test does one thing: it loads OpenCL and checks that the platform version matches "OpenCL 1.2 pocl X.Y". Two common ways this could fail are 1) you have another OpenCL platform installed, or 2) loading libpocl.so fails (usually due to linking problems). If you have ocl-icd installed as ICD loader, then an easy check is: source <path-to-pocl-source-dir>/tools/scripts/devel-envs.sh clinfo from pocl's BUILD directory. If it prints 0 platforms then likely you have linking issues. Or you could build pocl with -DENABLE_ICD=0 and it'll fail linking the tests, if there are any problems. Cheers, -- mb |
From: O. H. <oha...@wa...> - 2018-03-10 08:32:21
|
Trying to prepare an adaption of POCL 1.1 to FreeBSD (CURRENT at the moment), using LLVM/CLANG 5, compilation runs well, but the final tests fail due to the initial error in pocl_version_check, like [...] Start 1: pocl_version_check 1/197 Test #1: pocl_version_check ..................................................................***Failed Required regular expression not found.Regex=[basic ] [...] which then results (for me) in [...] 61% tests passed, 77 tests failed out of 197 Label Time Summary: EinsteinToolkit = 11.32 sec*proc (2 tests) VexCL = 0.00 sec*proc (27 tests) clBLAS = 0.00 sec*proc (46 tests) clFFT = 0.00 sec*proc (3 tests) cuda = 3.65 sec*proc (49 tests) hsa = 0.26 sec*proc (3 tests) internal = 11.82 sec*proc (107 tests) kernel = 3.33 sec*proc (29 tests) regression = 2.56 sec*proc (35 tests) runtime = 4.09 sec*proc (21 tests) spir = 0.86 sec*proc (1 test) tce = 0.69 sec*proc (9 tests) workgroup = 1.53 sec*proc (19 tests) Total Test time (real) = 172.05 sec The following tests FAILED: 1 - pocl_version_check (Failed) 122 - clBLAS_samples_example_chbmv (Not Run) 123 - clBLAS_samples_example_chemm (Not Run) [...] 194 - vexcl_scan_by_key (Not Run) 195 - vexcl_reduce_by_key (Not Run) 196 - vexcl_logical (Not Run) 197 - vexcl_threads (Not Run) Errors while running CTest FAILED: CMakeFiles/test.util cd /usr/ports/lang/pocl.svn/work/pocl-1.1 && /usr/local/bin/ctest --force-new-ctest-process ninja: build stopped: subcommand failed. *** Error code 1 [...] I haven't looked deeper into it, but I guess the lattice of failed tests above does result in the initial very first test, no. 1, designated "pocl_version_check", doesn't it? What is going wrong here? Does anybody else face this error? Thanks in advance, O. Hartmann -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). |
From: Andreas K. <li...@in...> - 2018-03-10 02:02:59
|
Hi all, Any clue what might be triggering this build failure on macOS with LLVM 5? https://travis-ci.org/conda-forge/pocl-feedstock/builds/351520947 Thanks! Andreas |
From: Michal B. <Fra...@ru...> - 2018-03-09 16:58:05
|
Hello everyone, Portable Computing Language (pocl) v1.1 released ------------------------------------------------- Pocl is a portable open source (MIT-licensed) implementation of the OpenCL standard (1.2 with some 2.0 features supported). In addition to producing an easily portable open-source OpenCL implementation, another major goal of this project is improving performance portability of OpenCL programs with the kernel compiler and the task runtime, reducing the need for target-dependent manual optimizations. Release highlights ------------------ * Support for LLVM/Clang 6.0 and 5.0. * Experimental SPIR and SPIR-V support * Improved kernel compilation speed For full details, please read the Changelog or 1.1 release page on GitHub (links at the bottom). Please note that there's an official pocl "maintenance policy" in place. This text describes the policy and how you can get your favourite project that uses OpenCL to remain regression free in the future pocl releases: http://portablecl.org/docs/html/maintainer-policy.html Acknowledgements ---------------- Most of the code that landed to the pocl code base during this release cycle was produced for the needs of research funded by various sources. The Customized Parallel Computing research group of Tampere University of Technology (Finland) likes to thank the Academy of Finland (funding decision 297548), Business Finland (FiDiPro project StreamPro, 1846/31/2014) and HSA Foundation. Links ----- GitHub release: https://github.com/pocl/pocl/releases/tag/v1.1 Home page: http://portablecl.org/ This announcement: http://portablecl.org/downloads/ANNOUNCEMENT Change log: http://portablecl.org/downloads/CHANGES Download: http://portablecl.org/downloads.html Regards, -- mb |
From: Michal B. <Fra...@ru...> - 2018-03-05 13:04:38
|
Hello, RC3 is out. This is very likely the last RC. Sources can be found at the usual place: https://github.com/pocl/pocl/releases/tag/v1.1-RC3 Regards, -- mb |
From: Michal B. <Fra...@ru...> - 2018-02-22 10:55:35
|
Hello, LLVM 6 is almost released, which means a new pocl release is near. This is mostly a bugfix release with only a few new features. Please help test and report any issues you find. Instructions: https://github.com/pocl/pocl/wiki/Release-testing-of-pocl-1.1 Sources: https://github.com/pocl/pocl/releases/tag/v1.1-RC1 Regards, -- mb |
From: Michal B. <Fra...@ru...> - 2018-02-11 20:37:11
|
Hello, Timo Betcke <tim...@gm...> wrote: > I have on my Kaby Lake laptop hand-vectorized the routine by > processing items in multiple of 8. > The performance of POCL is now within a factor of two of the Intel > OpenCL runtime with auto-vectorization. I've tried a changing your code in a few ways to get its loops vectorized, but i came to conclusion LLVM's loop-vectorizer is extremely picky and will fail to vectorize for many reasons. A few which i found: 1) if it cannot prove a vector instruction would handle all corner cases exactly the same way as scalar instruction (unsafe/fast-math options seems to somewhat alleviate this problem) 2) in some cases, branches and switches. Pocl may contain these in surprising places (e.g. distance(x, y) which is the same as length(x - y) - length contains branches to handle denorms / infinity). 3) certain memory access patterns & extractelement instruction (extracting elements of a vector). So.. the bad news is, LLVM will need a lot of improvement to vectorize this code automagically. The tiny good news is, >99% of kernel library functions which are listed here https://github.com/pocl/pocl/tree/master/lib/kernel/libclc-pocl and here https://github.com/pocl/pocl/tree/master/lib/kernel/sleef-pocl have been hand-vectorized and LLVM does indeed generate AVX1/2/512 code for them. So hand-vectorized code should be able to achieve speeds reasonably close to Intel's runtime. Regards, -- mb |
From: Timo B. <tim...@gm...> - 2018-02-11 01:52:07
|
Dear All, I have on my Kaby Lake laptop hand-vectorized the routine by processing items in multiple of 8. The performance of POCL is now within a factor of two of the Intel OpenCL runtime with auto-vectorization. So while not perfect this is good enough for us, and when Intel is available we can easily automatically switch to a corresponding Intel optimized routine. Best wishes Timo On 8 February 2018 at 23:15, Michal Babej <Fra...@ru...> wrote: > Hi, > > Nicholas Curtis <nic...@uc...> wrote: > > > Does LLVM have to be compiled in Debug mode in order for the output > > to work? > > Not sure if it has to be Debug, but i've noticed that it doesn't work > with all LLVM builds. It fails on my distro's LLVM, but works on my own > LLVM build (RelWithDebInfo+Asserts). > > -- mb > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel > -- Dr. Timo Betcke Reader in Mathematics University College London Department of Mathematics E-Mail: t.b...@uc... Tel.: +44 (0) 20-3108-4068 Fax.: +44 (0) 20-7383-5519 |
From: Michal B. <Fra...@ru...> - 2018-02-08 23:15:22
|
Hi, Nicholas Curtis <nic...@uc...> wrote: > Does LLVM have to be compiled in Debug mode in order for the output > to work? Not sure if it has to be Debug, but i've noticed that it doesn't work with all LLVM builds. It fails on my distro's LLVM, but works on my own LLVM build (RelWithDebInfo+Asserts). -- mb |
From: Andreas K. <li...@in...> - 2018-02-08 21:22:59
|
Jeff Hammond <jef...@gm...> writes: >> I've been treating POCL as useful tool for validation -- i.e., it's easy >> to install via conda, and unlike some other OpenCL runtimes (i.e., Intel... >> not that I mean to offend Jeff), you guys are very responsive to >> acknowledging / fixing bugs, or at least explaining why I shouldn't be >> doing something that breaks POCL. I'll add my 'me too' to that in that I'm in a similar situation to Timo and Nick. I reported an issue [1] similar in flavor to Timo's a while back, and any progress on making outer-loop vectorization in POCL for AVX* a reliable and predictable affair [2] has the potential for considerable impact in the computational science community. (I made the conda-forge packages for llvm and pocl, that's how much I believe that's true.) [1] https://github.com/pocl/pocl/issues/340 [2] (say, as predictable and reliable as ISPC, for the sake of argument) > I don't take offense to the suggestion that Intel OpenCL is nontrivial to > install (at the very least, it requires sudo) Heh. If you know exactly how to butcher the tarballs and RPMs, you *can* get by without root. Anyway, moving along... :) Andreas |
From: Michal B. <Fra...@ru...> - 2018-02-08 20:41:20
|
Hi, Timo Betcke <tim...@gm...> wrote: > which I already suspected. I tried POCL_VECTORIZER_REMARKS=1 to > activate vectorizer remarks. But it does not create any kind of Yes, it doesn't work - even if pocl registers the LLVM options to print debug info successfully.. i haven't yet figured out why it's not working. > The question is what prevents the auto vectorizer from working at > all. The code seems quite straight forward with very simple for-loops It's possible to use POCL_DEBUG_LLVM_PASSES=1 and grep for lines starting with "LV:" - this shows that vectorizer is in fact running. I tried to compile "evaluate_regular" from your .cl file. It seems to find two loops; the first one (smaller) is only vectorized when you build with "-cl-fast-relaxed-math" option. The second, longer loop prints this: LV: Checking a loop in "_pocl_launcher_evaluate_regular" from /tmp/POCL_CACHE/tempfile-4b-64-39-6d-57.cl LV: Loop hints: force=? width=0 unroll=0 LV: Found a loop: for.body.i LV: Found an induction variable. LV: We can vectorize this loop! LV: The Smallest and Widest types: 32 / 32 bits. LV: The Widest register is: 256 bits. LV: Scalar loop costs: 20. LV: Vector loop of width 2 costs: 38. LV: Vector loop of width 4 costs: 37. LV: Vector loop of width 8 costs: 36. LV: Selecting VF: 1. LV: Vectorization is possible but not beneficial. ... changing N_QUAD_POINTS doesn't seem to make any difference. Cheers, -- mb |
From: Jeff H. <jef...@gm...> - 2018-02-08 20:34:15
|
> > > I've been treating POCL as useful tool for validation -- i.e., it's easy > to install via conda, and unlike some other OpenCL runtimes (i.e., Intel... > not that I mean to offend Jeff), you guys are very responsive to > acknowledging / fixing bugs, or at least explaining why I shouldn't be > doing something that breaks POCL. > I don't take offense to the suggestion that Intel OpenCL is nontrivial to install (at the very least, it requires sudo) or that open-source projects often have lower latency support. There's a reason I'm on this list, after all ;-) Jeff -- Jeff Hammond jef...@gm... http://jeffhammond.github.io/ |