Menu
▾
▴
pocl-devel — Portable OpenCL development discussion
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: Pekka J. <pek...@tu...> - 2017-11-15 11:46:49
|
Hi, I think the debug info generation and preservation across WGF passes is unfinished. I typically end up using printf() when debugging kernel code, and look at the disassembly in gdb, which usually helps to spot the kernel lines where the crash happens. On 10.11.2017 10:33, Wuweijia wrote: > I write cl file , and ran it with the pocl in arm64 server, > compilation is ok. In the running there is some bug in the cl file, > and application crash in the cl file . How can I debug the cl file with gdb. > > I think the pocl compile the cl file with some optimized > options, no debug info. Show the gdb can not show me the callstack > where cl file crash. -- Pekka |
|
From: Wuweijia <wuw...@hu...> - 2017-11-10 09:33:55
|
HI,
I write cl file , and ran it with the pocl in arm64 server, compilation is ok. In the running there is some bug in the cl file, and application crash in the cl file . How can I debug the cl file with gdb.
I think the pocl compile the cl file with some optimized options, no debug info. Show the gdb can not show me the callstack where cl file crash.
BR
Owen
|
|
From: Michal B. <Fra...@ru...> - 2017-11-03 08:59:51
|
Hello, To fix some remaining issues with user events, i've done some changes to the event handling code. You can view it here (last 6 commits only): https://github.com/franz/pocl/commits/user_events In particular, pocl_broadcast() now calls notify on events also in CL_QUEUED state, and also calls notify on events which depend on failed *user* events. Some problems remain: 1) i've updated all drivers except CUDA which seems to have its own way of handling events. I'd appreciate if someone with knowledge of the CUDA driver could update the driver, or talk to me in private about fixing it 2) if i read the OpenCL spec correctly, after any event fails, the state is "implementation defined", so we need to pick a behavior. Calling abort() is probably undesirable ;) so i think we could mark the command queue(s) as invalid, stop accepting new commands into them, and set all dependent events to status failed; leave context and buffers untouched. Does anyone know how do other implementations handle this ? Comments / ideas welcome Regards, -- mb |
|
From: Michal B. <Fra...@ru...> - 2017-11-02 07:32:07
|
Hi, On Wed, 1 Nov 2017 19:26:48 -0400 Nicholas Curtis <nic...@uc...> wrote: > However, clCreateSubDevices *is* implemented in on the github repo (I > believe, > > Is this desired behavior? Or a bug? It's a bug. Not in clCreateSubDevices - that is fully implemented, but rather the CPU driver ignores it. Please file an issue on GitHub: https://github.com/pocl/pocl/issues -- mb |
|
From: Nicholas C. <nic...@uc...> - 2017-11-01 23:49:49
|
Hi all, I noticed that POCL (on ec8598d) always seems to use all cores on my machine, regardless of whether a subDevice has been set up. Following this I created a simple test script (attached, core_check.py) that varies both the number of cores supplied to clCreateSubDevices, as well as the desired platform (comparing against a reference Intel 16.1.1 CPU implementation). The results seem to imply that indeed, POCL doesn't respect the number of cores (compute units) passed in to clCreateSubDevices with type CL_DEVICE_PARTITION_BY_COUNTS: platform: pocl num cores: 1 elapsed time: 2.774392e+03 platform: pocl num cores: 2 elapsed time: 2.484821e+03 platform: pocl num cores: 4 elapsed time: 2.598454e+03 platform: pocl num cores: 8 elapsed time: 2.532769e+03 platform: pocl num cores: 16 elapsed time: 2.540196e+03 platform: Intel num cores: 1 elapsed time: 2.027040e+03 platform: Intel num cores: 2 elapsed time: 1.169391e+03 platform: Intel num cores: 4 elapsed time: 7.340540e+02 platform: Intel num cores: 8 elapsed time: 6.832930e+02 platform: Intel num cores: 16 elapsed time: 5.666650e+02 However, clCreateSubDevices *is* implemented in on the github repo (I believe, https://github.com/pocl/pocl/blob/a221e5b33efd89b3165f59cf15e67487e5a31076/lib/CL/clCreateSubDevices.c#L38) nor can I spot anything obviously wrong with it. Is this desired behavior? Or a bug? Thanks Nick |
|
From: Doug S. - A. <do...@ac...> - 2017-09-24 14:16:28
|
Good day Michal Thank you for the reply Looks like my Kali distro and updates are on GCC (7.2.0-4) gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/7/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-4' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 7.2.0 (Debian 7.2.0-4) So should I use the pocl-0.14 master ? I see that CMAKE has replaced configure but have not worked with CMAKE. Do you know of a help files to run cmake for pocl-0.14 ? also should I use clang+llvm-5.0.0 compiled for arm7a ? Thanks again for the help Doug ---------------------------------------- From: "Michal Babej" <Fra...@ru...> Sent: Sunday, September 24, 2017 4:13 AM To: poc...@li... Cc: do...@ac... Subject: Re: [pocl-devel] pocl-0.13 compile error ? Hi, On Wed, 20 Sep 2017 13:03:07 -0400 "Doug Shubert - AGS" <do...@ac...> wrote: > error: "isfinite is not a macro" > #error "isfinite is not a macro" This is caused by a new version of GCC (6.x) which changed some functions to macros. This has been reported: https://github.com/pocl/pocl/issues/357 .. and fixed in master. Also, as Pekka said, don't get your hopes too high with pocl+ARM, many things work but also quite a few do not. Cheers, -- mb |
|
From: Michal B. <Fra...@ru...> - 2017-09-24 08:10:22
|
Hi, On Wed, 20 Sep 2017 13:03:07 -0400 "Doug Shubert - AGS" <do...@ac...> wrote: > error: "isfinite is not a macro" > #error "isfinite is not a macro" This is caused by a new version of GCC (6.x) which changed some functions to macros. This has been reported: https://github.com/pocl/pocl/issues/357 .. and fixed in master. Also, as Pekka said, don't get your hopes too high with pocl+ARM, many things work but also quite a few do not. Cheers, -- mb |
|
From: Pekka J. <pek...@tu...> - 2017-09-21 07:03:39
|
Hi,
Please try with the latest master. There has been a lot of updates.
Also, there's currently noone actively maintaining the ARM port, so
please be prepared that you might need to contribute to the project to
get it working.
BR,
Pekka
On 20.09.2017 19:03, Doug Shubert - AGS wrote:
> Compiling pocl 0.13 on RPi 3 ARMv7 Processor rev 4 (v7l), OS is KALI
> kali-2017.01-rpi2
> All dependencies appear to be updated
> not sure how to resolve the compile errors.
> Please advise
> 64_base_atomics -Dcl_khr_int64_extended_atomics -c -o
> vecmathlib-pocl/acos.cc.bc ../../../lib/kernel/vecmathlib-pocl/acos.cc
> In file included from ../../../lib/kernel/vecmathlib-pocl/acos.cc:3:
> In file included from ../../../lib/kernel/vecmathlib-pocl/pocl-compat.h:8:
> In file included from
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/vecmathlib.h:89:
> In file included from
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/vec_pseudo.h:6:
> In file included from
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floatprops.h:6:
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:44:2:
> error: "isfinite is not a macro"
> #error "isfinite is not a macro"
> ^
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:47:2:
> error: "isinf is not a macro"
> #error "isinf is not a macro"
> ^
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:50:2:
> error: "isnan is not a macro"
> #error "isnan is not a macro"
> ^
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:53:2:
> error: "isnormal is not a macro"
> #error "isnormal is not a macro"
> ^
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:56:2:
> error: "signbit is not a macro"
> #error "signbit is not a macro"
> ^
> In file included from ../../../lib/kernel/vecmathlib-pocl/acos.cc:3:
> In file included from ../../../lib/kernel/vecmathlib-pocl/pocl-compat.h:8:
> In file included from
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/vecmathlib.h:93:
> In file included from
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/vec_builtin.h:7:
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floatbuiltins.h:10:42:
> warning: taking the absolute value of unsigned
> type 'char' has no effect [-Wabsolute-value]
> inline char builtin_abs(char x) { return __builtin_abs(x); }
> ^
> ../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floatbuiltins.h:10:42:
> note: remove the call to '__builtin_abs' since
> unsigned values cannot be negative
> inline char builtin_abs(char x) { return __builtin_abs(x); }
> ^~~~~~~~~~~~~
> 1 warning and 5 errors generated.
> Makefile:1154: recipe for target 'vecmathlib-pocl/acos.cc.bc' failed
> make[4]: *** [vecmathlib-pocl/acos.cc.bc] Error 1
> make[4]: Leaving directory '/root/pocl-0.13/lib/kernel/host'
> Makefile:481: recipe for target 'all-recursive' failed
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory '/root/pocl-0.13/lib/kernel'
> Makefile:465: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory '/root/pocl-0.13/lib'
> Makefile:640: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/root/pocl-0.13'
> Makefile:526: recipe for target 'all' failed
> make: *** [all] Error 2
> -Doug
>
>
> ------------------------------------------------------------------------------
> 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
>
--
Pekka
|
|
From: Doug S. - A. <do...@ac...> - 2017-09-20 17:14:42
|
Compiling pocl 0.13 on RPi 3 ARMv7 Processor rev 4 (v7l), OS is KALI
kali-2017.01-rpi2
All dependencies appear to be updated
not sure how to resolve the compile errors.
Please advise
64_base_atomics -Dcl_khr_int64_extended_atomics -c -o
vecmathlib-pocl/acos.cc.bc ../../../lib/kernel/vecmathlib-pocl/acos.cc
In file included from ../../../lib/kernel/vecmathlib-pocl/acos.cc:3:
In file included from ../../../lib/kernel/vecmathlib-pocl/pocl-compat.h:8:
In file included from
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/vecmathlib.h:89:
In file included from
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/vec_pseudo.h:6:
In file included from
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floatprops.h:6:
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:44:2: error:
"isfinite is not a macro"
#error "isfinite is not a macro"
^
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:47:2: error:
"isinf is not a macro"
#error "isinf is not a macro"
^
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:50:2: error:
"isnan is not a macro"
#error "isnan is not a macro"
^
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:53:2: error:
"isnormal is not a macro"
#error "isnormal is not a macro"
^
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floattypes.h:56:2: error:
"signbit is not a macro"
#error "signbit is not a macro"
^
In file included from ../../../lib/kernel/vecmathlib-pocl/acos.cc:3:
In file included from ../../../lib/kernel/vecmathlib-pocl/pocl-compat.h:8:
In file included from
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/vecmathlib.h:93:
In file included from
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/vec_builtin.h:7:
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floatbuiltins.h:10:42:
warning: taking the absolute value of unsigned
type 'char' has no effect [-Wabsolute-value]
inline char builtin_abs(char x) { return __builtin_abs(x); }
^
../../../lib/kernel/vecmathlib-pocl/../vecmathlib/floatbuiltins.h:10:42:
note: remove the call to '__builtin_abs' since
unsigned values cannot be negative
inline char builtin_abs(char x) { return __builtin_abs(x); }
^~~~~~~~~~~~~
1 warning and 5 errors generated.
Makefile:1154: recipe for target 'vecmathlib-pocl/acos.cc.bc' failed
make[4]: *** [vecmathlib-pocl/acos.cc.bc] Error 1
make[4]: Leaving directory '/root/pocl-0.13/lib/kernel/host'
Makefile:481: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/root/pocl-0.13/lib/kernel'
Makefile:465: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/root/pocl-0.13/lib'
Makefile:640: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/root/pocl-0.13'
Makefile:526: recipe for target 'all' failed
make: *** [all] Error 2
-Doug
|
|
From: Pekka J. <pek...@tu...> - 2017-09-18 09:07:36
|
Hi, On 8.9.2017 14:10, Catello Cioffi wrote: > "poclcc: error while loading shared libraries: libpoclu.so.1: cannot > open shared object file: No such file or directory" I think you miss the directory where you installed pocl libs from your dynamic linker's search paths. -- Pekka |
|
From: Catello C. <cat...@gm...> - 2017-09-08 12:10:34
|
Hi, I'm having trouble in executing poclcc after installation. I followed the instructions on the site http://portablecl.org/docs/html/install.html, in particular, I've created the "build" folder inside the pocl folder and run "cmake .." followed by "make" and "sudo make install". The building process finished successfully but when I try to execute "poclcc" it gives me this error: "poclcc: error while loading shared libraries: libpoclu.so.1: cannot open shared object file: No such file or directory" I'm using Ubuntu 16.04 LTS with an Intel i7-3770 CPU and an NVIDIA GeForce 210. I've also installed pocl on another PC running the same OS and this error doesn't appear. Is there something I've missed during the building process? Cheers, Catello |
|
From: Chris C. <chr...@gm...> - 2017-07-06 13:35:02
|
Sure thing Pekka https://github.com/pocl/pocl/issues/487 On Thu, Jul 6, 2017 at 1:16 PM Pekka Jääskeläinen <pek...@tu...> wrote: > Hi Chris, > > Can you please open Github issues of these? > > Please attach there the following additional info: > - LLVM version > - is it Intel E5-2620 specific -- does it work with some other target with > the same LLVM and pocl versions > > Thanks, > Pekka > > On 07/06/2017 02:26 PM, Chris Cummins wrote: > > Hi, > > > > I have been batch testing OpenCL programs and have encountered a number > of > > cases where pocl performs unusually. > > > > The first is when compiling a kernel with undefined symbols. In this > case, > > the compiler should error, however, with pocl, the compilation completes > > successfully, but the program then crashes due to a symbol lookup error > when > > trying to run the kernel. I have produced a standalone script here: > > > > http://paste.ubuntu.com/25031508/ (additional examples in the footer of > this > > email) > > > > Secondly, there are cases where the program silently crashes during > kernel > > execution with an error message. Example: > > > > http://paste.ubuntu.com/25031556/ (additional examples in the footer of > this > > email) > > > > In the above case, the kernel performs a mod zero operation which in the > > spec is undefined, though the kernel completes on NVIDIA/Intel OpenCL > > implementations. > > > > Cheers, > > Chris > > > > Additional examples of undefined symbol errors: > > > > http://paste.ubuntu.com/25031509/ > > http://paste.ubuntu.com/25031510/ > > http://paste.ubuntu.com/25031511/ > > http://paste.ubuntu.com/25031512/ > > http://paste.ubuntu.com/25031513/ > > http://paste.ubuntu.com/25031514/ > > http://paste.ubuntu.com/25031515/ > > http://paste.ubuntu.com/25031516/ > > http://paste.ubuntu.com/25031517/ > > http://paste.ubuntu.com/25031518/ > > http://paste.ubuntu.com/25031519/ > > http://paste.ubuntu.com/25031520/ > > http://paste.ubuntu.com/25031521/ > > http://paste.ubuntu.com/25031522/ > > http://paste.ubuntu.com/25031523/ > > http://paste.ubuntu.com/25031524/ > > http://paste.ubuntu.com/25031525/ > > http://paste.ubuntu.com/25031526/ > > http://paste.ubuntu.com/25031527/ > > http://paste.ubuntu.com/25031528/ > > http://paste.ubuntu.com/25031529/ > > http://paste.ubuntu.com/25031530/ > > http://paste.ubuntu.com/25031531/ > > http://paste.ubuntu.com/25031532/ > > http://paste.ubuntu.com/25031533/ > > http://paste.ubuntu.com/25031535/ > > http://paste.ubuntu.com/25031536/ > > http://paste.ubuntu.com/25031538/ > > http://paste.ubuntu.com/25031539/ > > > > Additional examples of runtime crashes: > > > > http://paste.ubuntu.com/25031555/ > > http://paste.ubuntu.com/25031557/ > > http://paste.ubuntu.com/25031558/ > > http://paste.ubuntu.com/25031559/ > > http://paste.ubuntu.com/25031561/ > > http://paste.ubuntu.com/25031562/ > > http://paste.ubuntu.com/25031563/ > > http://paste.ubuntu.com/25031564/ > > http://paste.ubuntu.com/25031565/ > > http://paste.ubuntu.com/25031566/ > > http://paste.ubuntu.com/25031567/ > > http://paste.ubuntu.com/25031568/ > > http://paste.ubuntu.com/25031569/ > > http://paste.ubuntu.com/25031570/ > > http://paste.ubuntu.com/25031571/ > > http://paste.ubuntu.com/25031572/ > > http://paste.ubuntu.com/25031573/ > > http://paste.ubuntu.com/25031574/ > > http://paste.ubuntu.com/25031575/ > > http://paste.ubuntu.com/25031576/ > > http://paste.ubuntu.com/25031577/ > > > > > > > ------------------------------------------------------------------------------ > > 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 > > > > -- > Pekka > |
|
From: Matthias N. <ma....@gm...> - 2017-06-28 14:33:43
|
Hi Benson,
the older Xeon Phi cards (KNC) have a special 512-bit SIMD instruction
set, that is not AVX-512, but can be seen as its predecessor. For those,
an older Intel SDK (14.2) is available, but support was removed without
any rationale in later releases. I got OpenMP-competitive performance
with that SDK on KNC, with automatic as well as with manual
vectorisation schemes.
https://software.intel.com/en-us/articles/opencl-drivers
Using PoCL on KNC would probably work if you manage to compile it
natively (along with all dependencies) on the KNC and run the host code
natively too.
On the fully x86-64 compatible KNL generation of the Xeon Phi, the Xeon
OpenCL driver with AVX2 can be used. As well as any other SDK supporting
x86/AVX (e.g. PoCL and AMD).
Cheers,
Matthias
On 28.06.2017 15:28, Benson Muite wrote:
> Hi Matthias,
>
> Your results are interesting. How did you get OpenCL to work on
> Knights landing? Would this work on older Xeon Phi cards?
>
> Regards,
> Benson
>
> On 06/28/2017 04:03 PM, Matthias Noack wrote:
>> Hi all,
>>
>> the following talk from IWOCL'17 has some numbers on PoCL on Xeon
>> (HSW), and Xeon Phi (KNL) for two applications using PoCL and other
>> SDKs:
>>
>> http://www.iwocl.org/wp-content/uploads/iwocl2017_matthias-noack-good-bad-ugly.pdf
>>
>>
>> The numbers for the comet simulation (slide 18, pdf 53), show some
>> weird outliers every 32 work-items, when increasing the overall
>> number of work-items (particles).
>>
>> The HEOM code reveals a large performance gap in comparison with the
>> Intel SDK on KNL, while is looks quite competitive on HSW. This is
>> especially strange, as the Intel SDK has only AVX2 support, while
>> PoCL should be able to generate AVX-512 code using LLVM. I compiled
>> PoCL and LLVM on the target architectures, and made sure the result
>> is an actual Haswell and KNL built.
>>
>> Is anyone interested in working on improving these issues?
>>
>> Thanks,
>> Matthias
>>
>>
>> ------------------------------------------------------------------------------
>>
>> 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
>
|
|
From: Andreas K. <li...@in...> - 2017-06-28 14:05:22
|
Hi Matthias, all, Matthias Noack <ma....@gm...> writes: > the following talk from IWOCL'17 has some numbers on PoCL on Xeon (HSW), > and Xeon Phi (KNL) for two applications using PoCL and other SDKs: > > http://www.iwocl.org/wp-content/uploads/iwocl2017_matthias-noack-good-bad-ugly.pdf > > The numbers for the comet simulation (slide 18, pdf 53), show some weird > outliers every 32 work-items, when increasing the overall number of > work-items (particles). > > The HEOM code reveals a large performance gap in comparison with the > Intel SDK on KNL, while is looks quite competitive on HSW. This is > especially strange, as the Intel SDK has only AVX2 support, while PoCL > should be able to generate AVX-512 code using LLVM. I compiled PoCL and > LLVM on the target architectures, and made sure the result is an actual > Haswell and KNL built. > > Is anyone interested in working on improving these issues? I use pocl extensively as my reference CL implementation on which all my numerical research codes are based. I naturally have an interest in making those run as fast as possible. While I (sadly) likely won't be able to contributed myself, I very likely might be able to contribute time in the form of student projects. If someone could identify "student-sized" subprojects of this endeavor, that'd be hugely helpful. :) Andreas |
|
From: Benson M. <ben...@ut...> - 2017-06-28 13:46:00
|
Hi Matthias, Your results are interesting. How did you get OpenCL to work on Knights landing? Would this work on older Xeon Phi cards? Regards, Benson On 06/28/2017 04:03 PM, Matthias Noack wrote: > Hi all, > > the following talk from IWOCL'17 has some numbers on PoCL on Xeon > (HSW), and Xeon Phi (KNL) for two applications using PoCL and other SDKs: > > http://www.iwocl.org/wp-content/uploads/iwocl2017_matthias-noack-good-bad-ugly.pdf > > > The numbers for the comet simulation (slide 18, pdf 53), show some > weird outliers every 32 work-items, when increasing the overall number > of work-items (particles). > > The HEOM code reveals a large performance gap in comparison with the > Intel SDK on KNL, while is looks quite competitive on HSW. This is > especially strange, as the Intel SDK has only AVX2 support, while PoCL > should be able to generate AVX-512 code using LLVM. I compiled PoCL > and LLVM on the target architectures, and made sure the result is an > actual Haswell and KNL built. > > Is anyone interested in working on improving these issues? > > Thanks, > Matthias > > > ------------------------------------------------------------------------------ > > 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 -- Hajussüsteemide Teadur Arvutiteaduse Instituut Tartu Ülikool J. Liivi 2, 50409 Tartu http://kodu.ut.ee/~benson ---- Research Fellow of Distributed Systems Institute of Computer Science University of Tartu J. Liivi 2 50409 Tartu, Estonia http://kodu.ut.ee/~benson |
|
From: Matthias N. <ma....@gm...> - 2017-06-28 13:03:22
|
Hi all, the following talk from IWOCL'17 has some numbers on PoCL on Xeon (HSW), and Xeon Phi (KNL) for two applications using PoCL and other SDKs: http://www.iwocl.org/wp-content/uploads/iwocl2017_matthias-noack-good-bad-ugly.pdf The numbers for the comet simulation (slide 18, pdf 53), show some weird outliers every 32 work-items, when increasing the overall number of work-items (particles). The HEOM code reveals a large performance gap in comparison with the Intel SDK on KNL, while is looks quite competitive on HSW. This is especially strange, as the Intel SDK has only AVX2 support, while PoCL should be able to generate AVX-512 code using LLVM. I compiled PoCL and LLVM on the target architectures, and made sure the result is an actual Haswell and KNL built. Is anyone interested in working on improving these issues? Thanks, Matthias |
|
From: Grant H F. <gra...@wm...> - 2017-06-15 19:37:40
|
hello, I have installed pocl using all of the default settings: cmake .., make, make install. When I try to link my program directly with pocl: gcc example1.c -o example `pkg-config --libs --cflags pocl` I get an error that ld can't find -lpocl. I have searched everywhere for libpocl.so and it is not in my build. There is libpoclu.so, libpoclu.so.1, pocl.pc. thanks |
|
From: Grant H F. <gra...@wm...> - 2017-05-17 19:23:20
|
Hello, I am trying to install pocl on Linux CentOS. I have all of the requirement software but when I run cmake it says that it cannot find hwloc. I have tried putting hwloc in my downloads folder and in the pocl folder. --checking for module 'hwloc' --package 'hwloc' not found CMake Error at CMakeLists.txt:190 (message): hwloc package is required! Thanks |
|
From: Thomas G. <tom...@ma...> - 2017-05-12 16:37:37
|
That’s very curious output. It does seem like some internal state in the llvm libs decided things were internally incorrect and called the abort.
Pekka’s comment about a smallish test case is right on. Clearly there must be some set of actions that is triggering the bug.
Which toolchain are you using by the way? You mention Android so just wondering if you might be using Google’s or something else ?
Best,
Tom
> On May 11, 2017, at 11:00 PM, Wuweijia <wuw...@hu...> wrote:
>
> Hi :
> What the meaning of the output. And then the program aborted. What it happened?
>
> In the call stack, the abort case by llvm. But why?
>
> ### autovectorizer enabled
> DominatorTree is not up to date!
> Computed:
> =============================--------------------------------
> Inorder Dominator Tree:
> [1] %entry {0,17}
> [2] %for.cond {1,16}
> [3] %for.body {2,3}
> [3] %for.end.r_exit {4,15}
> [4] %for.end {5,14}
> [5] %for.cond63 {6,13}
> [6] %for.body66 {7,8}
> [6] %for.end74.r_exit {9,12}
> [7] %for.end74 {10,11}
>
> Actual:
> =============================--------------------------------
> Inorder Dominator Tree:
> [1] %entry {0,19}
> [2] %for.cond {1,18}
> [3] %for.body {2,3}
> [3] %for.end.r_exit {4,17}
> [4] %for.end {5,16}
> [5] %for.end.postbarrier_dummy {6,15}
> [6] %for.cond63 {7,14}
> [7] %for.body66 {8,9}
> [7] %for.end74.r_exit {10,13}
> [8] %for.end74 {11,12}
> ==4435==
> ==4435== Process terminating with default action of signal 6 (SIGABRT)
> ==4435== at 0x52DE530: tgkill (tgkill.S:9)
> ==4435== by 0x52DB9CF: pthread_kill (pthread_kill.cpp:45)
> ==4435== by 0x5296D6B: raise (raise.cpp:34)
> ==4435== by 0x528F82F: abort (abort.cpp:57)
> ==4435== by 0xA0EE453: llvm::DominatorTree::verifyDomTree() const (in /system/lib64/libOpenCL.so.1)
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org <http://slashdot.org/>! http://sdm.link/slashdot_______________________________________________ <http://sdm.link/slashdot_______________________________________________>
> pocl-devel mailing list
> poc...@li... <mailto:poc...@li...>
> https://lists.sourceforge.net/lists/listinfo/pocl-devel <https://lists.sourceforge.net/lists/listinfo/pocl-devel>
|
|
From: Pekka J. <pek...@tu...> - 2017-05-12 05:09:38
|
Hi,
Really hard to say much from this. Please create a minimal
test case that produces this and file a bug in Github.
BR,
Pekka
On 05/12/2017 07:00 AM, Wuweijia wrote:
> Hi :
>
> What the meaning of the output. And then the program aborted. What it
> happened?
>
>
>
> In the call stack, the abort case by llvm. But why?
>
>
>
> ### autovectorizer enabled
> DominatorTree is not up to date!
> Computed:
> =============================--------------------------------
> Inorder Dominator Tree:
> [1] %entry {0,17}
> [2] %for.cond {1,16}
> [3] %for.body {2,3}
> [3] %for.end.r_exit {4,15}
> [4] %for.end {5,14}
> [5] %for.cond63 {6,13}
> [6] %for.body66 {7,8}
> [6] %for.end74.r_exit {9,12}
> [7] %for.end74 {10,11}
>
> Actual:
> =============================--------------------------------
> Inorder Dominator Tree:
> [1] %entry {0,19}
> [2] %for.cond {1,18}
> [3] %for.body {2,3}
> [3] %for.end.r_exit {4,17}
> [4] %for.end {5,16}
> [5] %for.end.postbarrier_dummy {6,15}
> [6] %for.cond63 {7,14}
> [7] %for.body66 {8,9}
> [7] %for.end74.r_exit {10,13}
> [8] %for.end74 {11,12}
> ==4435==
> ==4435== Process terminating with default action of signal 6 (SIGABRT)
> ==4435== at 0x52DE530: tgkill (tgkill.S:9)
> ==4435== by 0x52DB9CF: pthread_kill (pthread_kill.cpp:45)
> ==4435== by 0x5296D6B: raise (raise.cpp:34)
> ==4435== by 0x528F82F: abort (abort.cpp:57)
> ==4435== by 0xA0EE453: llvm::DominatorTree::verifyDomTree() const (in
> /system/lib64/libOpenCL.so.1)
>
>
>
> ------------------------------------------------------------------------------
> 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
>
--
Pekka
|
|
From: Wuweijia <wuw...@hu...> - 2017-05-12 04:02:11
|
Enviroment :
Guest OS : ANDROID
Cpu: aarch64
发件人: Wuweijia
发送时间: 2017年5月12日 12:01
收件人: 'poc...@li...' <poc...@li...>
抄送: Fanbohao <fan...@hu...>
主题: hello, there is question about the output of the pocl
Hi :
What the meaning of the output. And then the program aborted. What it happened?
In the call stack, the abort case by llvm. But why?
### autovectorizer enabled
DominatorTree is not up to date!
Computed:
=============================--------------------------------
Inorder Dominator Tree:
[1] %entry {0,17}
[2] %for.cond {1,16}
[3] %for.body {2,3}
[3] %for.end.r_exit {4,15}
[4] %for.end {5,14}
[5] %for.cond63 {6,13}
[6] %for.body66 {7,8}
[6] %for.end74.r_exit {9,12}
[7] %for.end74 {10,11}
Actual:
=============================--------------------------------
Inorder Dominator Tree:
[1] %entry {0,19}
[2] %for.cond {1,18}
[3] %for.body {2,3}
[3] %for.end.r_exit {4,17}
[4] %for.end {5,16}
[5] %for.end.postbarrier_dummy {6,15}
[6] %for.cond63 {7,14}
[7] %for.body66 {8,9}
[7] %for.end74.r_exit {10,13}
[8] %for.end74 {11,12}
==4435==
==4435== Process terminating with default action of signal 6 (SIGABRT)
==4435== at 0x52DE530: tgkill (tgkill.S:9)
==4435== by 0x52DB9CF: pthread_kill (pthread_kill.cpp:45)
==4435== by 0x5296D6B: raise (raise.cpp:34)
==4435== by 0x528F82F: abort (abort.cpp:57)
==4435== by 0xA0EE453: llvm::DominatorTree::verifyDomTree() const (in /system/lib64/libOpenCL.so.1)
|
|
From: Wuweijia <wuw...@hu...> - 2017-05-12 04:00:47
|
Hi :
What the meaning of the output. And then the program aborted. What it happened?
In the call stack, the abort case by llvm. But why?
### autovectorizer enabled
DominatorTree is not up to date!
Computed:
=============================--------------------------------
Inorder Dominator Tree:
[1] %entry {0,17}
[2] %for.cond {1,16}
[3] %for.body {2,3}
[3] %for.end.r_exit {4,15}
[4] %for.end {5,14}
[5] %for.cond63 {6,13}
[6] %for.body66 {7,8}
[6] %for.end74.r_exit {9,12}
[7] %for.end74 {10,11}
Actual:
=============================--------------------------------
Inorder Dominator Tree:
[1] %entry {0,19}
[2] %for.cond {1,18}
[3] %for.body {2,3}
[3] %for.end.r_exit {4,17}
[4] %for.end {5,16}
[5] %for.end.postbarrier_dummy {6,15}
[6] %for.cond63 {7,14}
[7] %for.body66 {8,9}
[7] %for.end74.r_exit {10,13}
[8] %for.end74 {11,12}
==4435==
==4435== Process terminating with default action of signal 6 (SIGABRT)
==4435== at 0x52DE530: tgkill (tgkill.S:9)
==4435== by 0x52DB9CF: pthread_kill (pthread_kill.cpp:45)
==4435== by 0x5296D6B: raise (raise.cpp:34)
==4435== by 0x528F82F: abort (abort.cpp:57)
==4435== by 0xA0EE453: llvm::DominatorTree::verifyDomTree() const (in /system/lib64/libOpenCL.so.1)
|
|
From: Pekka J. <pek...@tu...> - 2017-04-25 08:59:57
|
Hi all, pocl-cuda has landed to 'master': "pocl now has experimental support for NVIDIA GPU devices via a new backend which makes use of the LLVM NVPTX backend and the CUDA driver API. This work was primarily carried out by James Price from the High Performance Computing group at the University of Bristol." http://portablecl.org/cuda-backend.html BR, -- Pekka |
5 messages has been excluded from this view by a project administrator.