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...> - 2022-05-20 09:15:52
|
Hi Matthias, Lately the reported issues have been more often race conditions or other bugs in the application side code rather than bugs in PoCL. These can appear as the program working as expected (by luck) in one OpenCL platform, but not the other. Can you try with the latest version (3.0-RC1) and the latest LLVM to see if there's any difference? If it fails, a simplified reproducer is needed to track the issue - otherwise it's only guesswork. BR, Pekka On 5/20/22 00:56, Matthias Bock wrote: > Hi, > > I am experiencing an incorrect behaviour > when running OpenCL kernels via pocl: > > I wrote an application in C/C++ > calling kernels written in OpenCL C. > It is a numerical simulation of the propagation > of an electrical stimulus on tissue, > from point to point on a 3D mesh > with thousands of points. > > On one computer I run it > with Intel's Open Source Beignet driver > on an Ivy Bridge GT2 featuring 16 compute units. > Calculation is time consuming, but the results are good: > A wavefront of excitation forms and travels across > the mesh as one would expect. > > When I run the identical source code with pocl > on a machine featuring a Xeon L5640 showing 23 compute units, > the results are completely different i.e. incorrect: > The stimulus is not propagating in a wavefront, > but instead wanders in random lines across the mesh. > > The platform is > OpenCL 1.2 pocl 1.6, None+Asserts, LLVM 9.0.1, > RELOC, SLEEF, DISTRO, POCL_DEBUG. > The device is > pthread-Intel(R) Xeon(R) CPU L5640 @ 2.27GHz > OpenCL 1.2 pocl HSTR: pthread-x86_64-pc-linux-gnu-westmere. > > Unfortunately, I can't share the original source code, > but I suspect some sort of race condition or the > queue not being executed in the correct order. > Inserting global memory barriers in all kernels > and adding queue flush & finish calls > in the main program after every kernel call > didn't change anything though. > > Do you have any ideas or suggestions? > > Cheers, > Matthias > > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel |
From: Matthias B. <ma...@ma...> - 2022-05-19 22:19:21
|
Hi, I am experiencing an incorrect behaviour when running OpenCL kernels via pocl: I wrote an application in C/C++ calling kernels written in OpenCL C. It is a numerical simulation of the propagation of an electrical stimulus on tissue, from point to point on a 3D mesh with thousands of points. On one computer I run it with Intel's Open Source Beignet driver on an Ivy Bridge GT2 featuring 16 compute units. Calculation is time consuming, but the results are good: A wavefront of excitation forms and travels across the mesh as one would expect. When I run the identical source code with pocl on a machine featuring a Xeon L5640 showing 23 compute units, the results are completely different i.e. incorrect: The stimulus is not propagating in a wavefront, but instead wanders in random lines across the mesh. The platform is OpenCL 1.2 pocl 1.6, None+Asserts, LLVM 9.0.1, RELOC, SLEEF, DISTRO, POCL_DEBUG. The device is pthread-Intel(R) Xeon(R) CPU L5640 @ 2.27GHz OpenCL 1.2 pocl HSTR: pthread-x86_64-pc-linux-gnu-westmere. Unfortunately, I can't share the original source code, but I suspect some sort of race condition or the queue not being executed in the correct order. Inserting global memory barriers in all kernels and adding queue flush & finish calls in the main program after every kernel call didn't change anything though. Do you have any ideas or suggestions? Cheers, Matthias |
From: Michal B. (TAU) <mic...@tu...> - 2022-03-28 12:23:15
|
Hello, Unfortunately no, there is no manual for mingw compilation. I have tried it maybe 2-3 years ago, but i didn't finish the work and i don't have any manual. Regards, -- mb ________________________________ From: ComputerFreak <ca...@na...> Sent: Friday, March 18, 2022 12:01 AM To: Portable Computing Language development discussion <poc...@li...> Subject: Re: [pocl-devel] Windows Build Instruction Thank you, Michal. Would there be any manual on building with MinGW compiler toolchain? I would love to try out somehow. Best regards, Dalas -----Original Message----- From: "Michal Babej (TAU)"<mic...@tu...> To: "poc...@li..."<poc...@li...>; Cc: Sent: 2022-03-18 (금) 00:35:49 (GMT+09:00) Subject: Re: [pocl-devel] Windows Build Instruction Hello, You might have success building PoCL on Windows 10 with WSL; building with MinGW compiler is likely broken (but possibly fixable with some work), and building with MSCV compiler is completely broken (and would require lot of work to fix). Regards, -- mb [https://mail.naver.com/readReceipt/notify/?img=i%2FbsWzeTM6KdaAvqKoKYFAu%2FaxErKx%2BSpoUqpx2%2FKoivpAI4KoMlFxCgMr9Xp6UmKLl5WLl5pNiC740ThoRmWrFn7630%2B4kntzwGbX3q7NFT%2BBiop6pTb4%2B074l0%2Bg%3D%3D.gif] |
From: ComputerFreak <ca...@na...> - 2022-03-17 22:01:54
|
Thank you, Michal. Would there be any manual on building with MinGW compiler toolchain? I would love to try out somehow. Best regards, Dalas -----Original Message----- From: "Michal Babej (TAU)"<mic...@tu...> To: "poc...@li..."<poc...@li...>; Cc: Sent: 2022-03-18 (금) 00:35:49 (GMT+09:00) Subject: Re: [pocl-devel] Windows Build Instruction Hello, You might have success building PoCL on Windows 10 with WSL; building with MinGW compiler is likely broken (but possibly fixable with some work), and building with MSCV compiler is completely broken (and would require lot of work to fix). Regards, -- mb |
From: Michal B. (TAU) <mic...@tu...> - 2022-03-17 18:10:03
|
Hello, You might have success building PoCL on Windows 10 with WSL; building with MinGW compiler is likely broken (but possibly fixable with some work), and building with MSCV compiler is completely broken (and would require lot of work to fix). Regards, -- mb [https://mail.naver.com/readReceipt/notify/?img=iwnsWzeTM6KdFxJvpAEYKoUZMrMdMoEZax2%2FM6JvKourFq2wpAF0MdIo%2BrkSKAgw74lR74l4b4u516YQaXITMrmRpzkrp6wgWz0q%2BHK5bre9b4F0p4eZprE5W4kd.gif] |
From: ComputerFreak <ca...@na...> - 2022-03-15 12:23:33
|
Hello, I currently am trying to use PoCL in my Windows PC. But the instruction or the script seems pretty old. Can I know the status on Windows build? Thanks, Dalas |
From: Isuru F. <is...@gm...> - 2021-10-19 17:58:05
|
Hi, > How would I go about compiling pocl as a CPU only driver and have it coexist with any other graphics drivers in the system providing OpenCL on the GPUs so it shows just as another CPU OpenCL device? You can build pocl with `ENABLE_ICD=yes` and then copy `pocl.icd` to /etc/OpenCL/vendors > Does pocl support Apple's M1 chip as a CPU device? Yes. (Shameless plug: I've packaged pocl for conda package manager for arm64-apple-darwin, x86_64-apple-darwin, x86_64-linux-gnu, aarch64-linux-gnu, ppc64le-linux-gnu. If you want binary packages, you can check them out.) Isuru On Tue, Oct 19, 2021 at 7:55 AM Asdiel Echevarria < asd...@gm...> wrote: > Hello! > > We develop a consumer application with heavy computation. We use OpenCL > in Windows and Metal in OSX to compute stuff in existing GPUs, but we also > need to provide a CPU only code path in both platforms. I would like to be > able to have a reliable CPU OpenCL driver for those two platforms. > > A couple of questions: > > How would I go about compiling pocl as a CPU only driver and have it > coexist with any other graphics drivers in the system providing OpenCL on > the GPUs so it shows just as another CPU OpenCL device? > > Does pocl support Apple's M1 chip as a CPU device? > > Thanks! > > > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel > |
From: Asdiel E. <asd...@gm...> - 2021-10-19 12:55:15
|
Hello! We develop a consumer application with heavy computation. We use OpenCL in Windows and Metal in OSX to compute stuff in existing GPUs, but we also need to provide a CPU only code path in both platforms. I would like to be able to have a reliable CPU OpenCL driver for those two platforms. A couple of questions: How would I go about compiling pocl as a CPU only driver and have it coexist with any other graphics drivers in the system providing OpenCL on the GPUs so it shows just as another CPU OpenCL device? Does pocl support Apple's M1 chip as a CPU device? Thanks! |
From: Pekka J. <pek...@tu...> - 2021-10-12 21:10:45
|
PoCL is a portable open source (MIT-licensed) implementation of the OpenCL standard (1.2 with some 2.0 and 3.0 features supported). In addition to being an easily portable multi-device (truly heterogeneous) open-source OpenCL implementation, a major goal of this project is improving interoperability for diversity of OpenCL-capable devices by integrating them to a single centrally orchestrated platform. Another key goal is to enhance performance portability of OpenCL programs across device types utilizing runtime and compiler techniques. Upstream PoCL currently supports various CPUs, NVIDIA GPUs via libcuda, HSA-supported GPUs and ASIPs (experimental, see: http://openasip.org). It is also known to have multiple (private) adaptations in active production use. Release Highlights ------------------ * Support for Clang/LLVM 13.0 * Improved debugging support with Valgrind, LTTNG * Improved support for NetBSD, Mac OS X * Improved support for SPIR/SPIR-V on CUDA Misc. Notes ----------- * 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 * We are still looking for an ARM and RISC-V CPU maintainers. If you are interested in ensuring a PoCL stays stable for these processor architectures, please let us know! Acknowledgements ---------------- Customized Parallel Computing (CPC) research group of Tampere University, Finland leads the development of PoCL on the side and for the needs of their research projects. This project has received funding from the ECSEL Joint Undertaking (JU) under grant agreement No 783162 (FitOptiVis). The JU receives support from the European Union’s Horizon 2020 research and innovation programme and Netherlands, Czech Republic, Finland, Spain, Italy. It was also supported by European Union's Horizon 2020 research and innovation programme under Grant Agreement No 871738 (CPSoSaware). The financial support is very much appreciated -- it keeps the open source project going! Links ----- Release web page: http://portablecl.org/pocl-1.8.html This announcement: http://portablecl.org/downloads/ANNOUNCEMENT Change log: http://portablecl.org/downloads/CHANGES Download: http://portablecl.org/download.html -- Pekka |
From: Michal B. (TAU) <mic...@tu...> - 2021-10-01 18:52:32
|
Hello all, LLVM 13.0 is near release, so we're preparing a new PoCL release. I've created RC1: https://github.com/pocl/pocl/releases/tag/v1.8-RC1 Please test and report your results here: https://github.com/pocl/pocl/wiki/Release-testing-of-pocl-1.8 or file issues in GitHub. Regards, -- MB |
From: Timo B. <tim...@gm...> - 2021-07-18 20:23:16
|
Hi, thanks for the tips. I have opened a bug report at https://github.com/conda-forge/pocl-feedstock/issues/67. The following is copied over from there as response to Michal's tips: --------------------- Tried out the following recommendation: llc --version in conda correctly identifies my CPU as skylake Running the kernel in debug mode with gdb gives a segfault in the following function in the conda version of pocl: Thread 1 "python" received signal SIGSEGV, Segmentation fault. 0x00007fff651618cc in llvm::TargetPassConfig::addPass(llvm::Pass*, bool, bool) () from /home/betcke/miniconda3/envs/bempp_test/lib/./libLLVM-11.so My distribution version of pocl is built on top of llvm 12. The conda version is built on top of LLVM 11. If I manually try to upgrade the conda version to libllvm 12 the conda dependency resolution wants to remove pocl. -------------------------- Hopefully the gdb message may give some clues. Best wishes Timo On Fri, 16 Jul 2021 at 14:33, Michal Babej (TAU) <mic...@tu...> wrote: > > Hello, > > __private double8' (vector of 8 'double' values) without 'avx512f' enabled changes the ABI > > Can you make sure that LLVM inside the Conda environment doesn't misdetect the CPU ? > Can be checked with llc command from LLVM package. Running llc --version should print something like: > > Optimized build. > Default target: x86_64-pc-linux-gnu > Host CPU: znver1 > > Finally, after all these warnings the code segfaults, which I did not see in the distribution provided pocl version. > > This definitely shouldn't happen even with the warnings. > > code can be generated that includes the type double16, but is never actually called as function in the kernel. > > Using wider vectors than CPU has should work properly, so i think that's fine. Can you try looking into doc/sphinx/source/debug.rst document, the "Debugging with GDB" section has a guide on compiling & running non-optimized -O0 version of your kernel. If it doesn't crash with -O0 code, it could be a bug somewhere in pocl's LLVM code. > > Regards, > Michal > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel -- Timo Betcke Professor of Computational Mathematics University College London Department of Mathematics E-Mail: t.b...@uc... Tel.: +44 (0) 20-3108-4068 |
From: Michal B. (TAU) <mic...@tu...> - 2021-07-16 13:33:23
|
Hello, __private double8' (vector of 8 'double' values) without 'avx512f' enabled changes the ABI Can you make sure that LLVM inside the Conda environment doesn't misdetect the CPU ? Can be checked with llc command from LLVM package. Running llc --version should print something like: Optimized build. Default target: x86_64-pc-linux-gnu Host CPU: znver1 Finally, after all these warnings the code segfaults, which I did not see in the distribution provided pocl version. This definitely shouldn't happen even with the warnings. code can be generated that includes the type double16, but is never actually called as function in the kernel. Using wider vectors than CPU has should work properly, so i think that's fine. Can you try looking into doc/sphinx/source/debug.rst document, the "Debugging with GDB" section has a guide on compiling & running non-optimized -O0 version of your kernel. If it doesn't crash with -O0 code, it could be a bug somewhere in pocl's LLVM code. Regards, Michal |
From: Andreas K. <li...@in...> - 2021-07-12 19:52:34
|
Hi Timo, Timo Betcke <tim...@gm...> writes: > I tried to track back conda versions of Pocl that were working fine. The > latest build that works well without segfaults or warnings was Pocl 1.5 > Build hecece54_6. Some later builds of 1.5 could also work well. But conda > has issues with dependency resolution and I had problems installing them. > > I would be very grateful for any pointer what could be going wrong. > > Just as a side info (in case it is useful) why code paths of type double8 > and double16 are created. We have a header file with certain inline > functions and implementations of them for all possible vector widths. The > actual type (double or single) is chosen via preprocessor parameter and the > correct function then called in the kernel as an inline function. Hence, > code can be generated that includes the type double16, but is never > actually called as function in the kernel. You can file issues about the conda package here: https://github.com/conda-forge/pocl-feedstock In the meantime, were you able to observe any correlation with the LLVM versions that are being used? The conda packages is still on LLVM 11, whereas Arch is conceivably already on 12: https://github.com/conda-forge/pocl-feedstock/blob/ecaf20dcb0693e6bcacc638912ba0ae0de616136/recipe/meta.yaml#L6 Andreas |
From: Timo B. <tim...@gm...> - 2021-07-10 08:59:33
|
Hi, I have the following issue on Arch Linux (and some of our users reported this issue also on other Linux systems). If I run the native distribution provided version of pocl 1.7 everything works fine. If I install the conda version I get lots of warnings of the type: __private double8' (vector of 8 'double' values) without 'avx512f' enabled changes the ABI '__private double16' (vector of 16 'double' values) without 'avx512f' enabled changes the ABI in code paths that are compiled into the kernel but not executed. Finally, after all these warnings the code segfaults, which I did not see in the distribution provided pocl version. I tried to track back conda versions of Pocl that were working fine. The latest build that works well without segfaults or warnings was Pocl 1.5 Build hecece54_6. Some later builds of 1.5 could also work well. But conda has issues with dependency resolution and I had problems installing them. I would be very grateful for any pointer what could be going wrong. Just as a side info (in case it is useful) why code paths of type double8 and double16 are created. We have a header file with certain inline functions and implementations of them for all possible vector widths. The actual type (double or single) is chosen via preprocessor parameter and the correct function then called in the kernel as an inline function. Hence, code can be generated that includes the type double16, but is never actually called as function in the kernel. Best wishes Timo -- Timo Betcke Professor of Computational Mathematics University College London Department of Mathematics E-Mail: t.b...@uc... Tel.: +44 (0) 20-3108-4068 |
From: Michal B. (TAU) <mic...@tu...> - 2021-05-19 13:29:57
|
Hello all, PoCL 1.7 has just been released. Highlights: * Support for Clang/LLVM 12.0 * Improved support for cross-compiling * Improved support for SPIR-V binaries when using CPU device Links: Home page: http://portablecl.org/ Change log: http://portablecl.org/downloads/CHANGES Download: http://portablecl.org/download.html Regards, -- mb |
From: Michal B. (TAU) <mic...@tu...> - 2021-04-19 12:31:14
|
Hello all, LLVM 12.0 was released, so we're preparing a new release. I've created RC1: https://github.com/pocl/pocl/releases/tag/v1.7-RC1 Please test and report your results here: https://github.com/pocl/pocl/wiki/Release-testing-of-pocl-1.7 Regards, -- mb |
From: Pekka J. <pek...@tu...> - 2020-12-21 13:42:24
|
Hi, Hartmann, O. kirjoitti 19.12.2020 klo 11.28: > p.s. It is a pity that cpuinfo.c and so POCL 1.6 is still narrowed down to Linux ... Are you stepping up to be a FreeBSD maintainer? If so, I'm very happy to hear that. First, can you formulate your patch as a pull request? Second, if there's a RC, please test it early enough on your platform of interest so the possible fixes can be applied in time for the release. I remind that PoCL is an open source project that is currently developed and maintained by people with limited time and on the side of other projects. Thus they have to put their "PoCL time" to what they need from the project urgently. From our group's perspective, we do not currently need FreeBSD in our work, thus it's not maintaned nor tested actively by us. Best regards, -- Pekka |
From: Hartmann, O. <oha...@wa...> - 2020-12-19 09:41:46
|
On Thu, 3 Dec 2020 01:27:54 +0000 "Michal Babej (TAU)" <mic...@tu...> wrote: > Hello all, > > LLVM 11.0 was released, so it's time for a new PoCL release. > I've created RC1: > > https://github.com/pocl/pocl/releases/tag/v1.6-RC1 > > Please test and report your results here: > https://github.com/pocl/pocl/wiki/Release-testing-of-pocl-1.6 > > Regards, > -- mb > Hello, there seems a problem with lib/CL/devices/cpuinfo.c. Compiling the release of POCL 1.6 fails with a "undefined reference", host is FreeBSD 12-STABLE, amd64, (FreeBSD 12.2-STABLE #53 r368766: Fri Dec 18 18:34:25 CET 2020 amd64), utilizing LLVM11. The code seems to lack some necessary type definitions: --- lib/CL/devices/cpuinfo.c.orig 2020-12-16 14:02:13.000000000 +0100 +++ lib/CL/devices/cpuinfo.c.patched 2020-12-19 10:21:52.546664000 +0100 @@ -415,8 +415,8 @@ */ if (!device->vendor_id) { - f = fopen (pci_bus_root_vendor_file, "r"); - num_read = fscanf (f, "%x", &device->vendor_id); + FILE *f = fopen (pci_bus_root_vendor_file, "r"); + int num_read = fscanf (f, "%x", &device->vendor_id); fclose (f); /* no error checking, if it failed we just won't have the info */ } Kind regards O. Hartmann p.s. It is a pity that cpuinfo.c and so POCL 1.6 is still narrowed down to Linux ... |
From: Pekka J. <pek...@tu...> - 2020-12-16 16:42:04
|
PoCL is a portable open source (MIT-licensed) implementation of the OpenCL standard (1.2 with some 2.0 features supported). In addition to being an easily portable multi-device (truely heterogeneous) open-source OpenCL implementation, a major goal of this project is improving interoperability of diversity of OpenCL-capable devices by integrating them to a single centrally orchestrated platform. Also one of the key goals longer term is to enhance performance portability of OpenCL programs across device types utilizing runtime and compiler techniques. Upstream PoCL currently supports various CPUs, NVIDIA GPUs via libcuda, HSA-supported GPUs and TCE ASIPs (experimental, see: http://openasip.org). It is also known to have multiple (private) adaptations in active production use. Release Highlights ------------------ * Support for Clang/LLVM 11.0 * Improved CUDA performance and features * Improved PowerPC support * Enhanced OpenCL debugging usage * Improved packaging support Misc. Notes ----------- * 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 * We are still looking for an ARM CPU maintainer, if you are interested putting in a bit of effort to make PoCL great(er) for ARM CPU devices, please let us know! * Same goes for the RISC-V CPU device support. * After a long while we have settled on the writing format of the project name abbreviation: The preferred one is PoCL, but the lower case 'pocl' remains as the secondary "old school" spelling form ;-) Acknowledgements ---------------- The CUDA improvements, PowerPC support and packaging support described in this post were made by Isuru Fernando and Matt Wala with assistance from Nick Christensen, and Andreas Klöckner, all part of the Department of Computer Science at the University of Illinois at Urbana-Champaign. The work was partially supported through awards OAC-1931577 and SHF-1911019 from the US National Science Foundation, as well as award DE-NA0003963 from the US Department of Energy. Customized Parallel Computing (CPC) research group of Tampere University, Finland leads the development of PoCL on the side and for the needs of their research projects. This project has received funding from the ECSEL Joint Undertaking (JU) under grant agreement No 783162 (FitOptiVis). The JU receives support from the European Union’s Horizon 2020 research and innovation programme and Netherlands, Czech Republic, Finland, Spain, Italy. It was also supported by European Union's Horizon 2020 research and innovation programme under Grant Agreement No 871738 (CPSoSaware) and HSA Foundation. The financial support is very much appreciated -- it keeps the open source project going! Links ----- Release web page: http://portablecl.org/pocl-1.6.html This announcement: http://portablecl.org/downloads/ANNOUNCEMENT Change log: http://portablecl.org/downloads/CHANGES Download: http://portablecl.org/download.html -- Pekka |
From: Michal B. (TAU) <mic...@tu...> - 2020-12-03 09:01:24
|
Hello all, LLVM 11.0 was released, so it's time for a new PoCL release. I've created RC1: https://github.com/pocl/pocl/releases/tag/v1.6-RC1 Please test and report your results here: https://github.com/pocl/pocl/wiki/Release-testing-of-pocl-1.6 Regards, -- mb |
From: Pekka J. <pek...@tu...> - 2020-09-21 12:50:24
|
Dear suhas hv, On 18.9.2020 8.50, suhas hv wrote: > I would like to run the example fixed function accelerator. I am > following the instructions under the section "System-on-a-chip design > with AlmaIF Integrator" in the TCE user manual. However I am not able to > execute the very first step of generating the processor. I am unable to > build TCE on my computer even though I am following the instructions > given. The error is to do with LLVM and I'm not sure of how to resolve it. TCE is an independent project from PoCL, thus the problems related to its build thus belong to its github or mailing list available via http://openasip.org. Anyways: "Problems with LLVM and TCE" usually are related to getting the system in the way with the TCE-patched LLVM. Ensure this doesn't happen via proper environment variables and it likely fixes your issues (I've seen this multiple times). > I am unsure as to whether this first step of generating the processor is > necessary since the VHDL code of the accelerator is already present in > the POCL github repository. I have tried to include the RTL Not necessary, that's why we included the RTL of the example accelerator to avoid the need to install TCE. You should be able to skip the ASIP generation and start from 3.12.3. > Can the steps involved in running the example fixed function accelerator > kindly be shared with me? The steps are there. We tested them with another student (than who wrote the manual steps) in our group independently and he was able to reproduce the accelerator execution with these steps. If you have challenges with Vivado, those questions belong to Xilinx tool support channels. BR, -- Pekka |
From: Pekka J. <pek...@tu...> - 2020-09-21 12:00:20
|
...one Vivado-hint though: In newer Vivado versions you might not see "Add block...", but "Add module...". On 21.9.2020 13.15, Pekka Jääskeläinen wrote: > The steps are there. We tested them with another student (than who > wrote the manual steps) in our group independently and he was able to > reproduce the accelerator execution with these steps. If you have > challenges with Vivado, those questions belong to Xilinx tool support > channels. -- Pekka |
From: suhas hv <suh...@gm...> - 2020-09-18 05:51:11
|
I would like to run the example fixed function accelerator. I am following the instructions under the section "System-on-a-chip design with AlmaIF Integrator" in the TCE user manual. However I am not able to execute the very first step of generating the processor. I am unable to build TCE on my computer even though I am following the instructions given. The error is to do with LLVM and I'm not sure of how to resolve it. I am unsure as to whether this first step of generating the processor is necessary since the VHDL code of the accelerator is already present in the POCL github repository. I have tried to include the RTL sub-directory in github in a Vivado project. However I am unable to instantiate the TTA cores in the block design as TTA core does not get listed as an IP. Can the steps involved in running the example fixed function accelerator kindly be shared with me? Thanks and regards Suhas |
From: Shazz <sh...@me...> - 2020-07-20 16:36:36
|
Hi, I have compiled and installed pocl with CUDA support on my NVIDIA Jetson TX2 and when I ran the tests, I got a lot of failed tests (mostly with the same error: regular expression found in output. Regex=[FAIL]), is it expected? Results: ../tools/scripts/run_cuda_tests Using OCL_ICD_VENDORS: /home/nvidia/openCL/pocl/build/ocl-vendors ... 58% tests passed, 29 tests failed out of 69 Label Time Summary: cuda = 155.97 sec*proc (69 tests) hsa = 6.62 sec*proc (4 tests) hsa-native = 138.55 sec*proc (56 tests) internal = 155.97 sec*proc (69 tests) kernel = 89.46 sec*proc (20 tests) regression = 46.02 sec*proc (28 tests) runtime = 10.50 sec*proc (14 tests) tce = 14.77 sec*proc (9 tests) Total Test time (real) = 156.06 sec The following tests FAILED: 26 - kernel/test_shuffle_char (Failed) 27 - kernel/test_shuffle_short (Failed) 28 - kernel/test_shuffle_ushort (Failed) 30 - kernel/test_shuffle_int (Failed) 31 - kernel/test_shuffle_uint (Failed) 32 - kernel/test_shuffle_float (Failed) 33 - kernel/test_shuffle_long (Failed) 34 - kernel/test_shuffle_ulong (Failed) 37 - kernel/test_shuffle_double (Failed) 44 - regression/phi_nodes_not_replicated_REPL (Failed) 46 - regression/barrier_between_two_for_loops_REPL (Failed) 47 - regression/simple_for-loop_with_a_barrier_inside_REPL (Failed) 48 - regression/for-loop_with_computation_after_the_brexit_REPL (Failed) 49 - regression/for-loop_with_a_variable_iteration_count_REPL (Failed) 50 - regression/early_return_before_a_barrier_region_REPL (Failed) 51 - regression/id-dependent_computation_before_kernel_exit_REPL (Failed) 52 - regression/barrier_just_before_return_REPL (Failed) 54 - regression/undominated_variable_from_conditional_barrier_handling_REPL (Failed) 68 - regression/phi_nodes_not_replicated_LOOPS (Failed) 70 - regression/barrier_between_two_for_loops_LOOPS (Failed) 71 - regression/simple_for-loop_with_a_barrier_inside_LOOPS (Failed) 72 - regression/for-loop_with_computation_after_the_brexit_LOOPS (Failed) 73 - regression/for-loop_with_a_variable_iteration_count_LOOPS (Failed) 74 - regression/early_return_before_a_barrier_region_LOOPS (Failed) 76 - regression/barrier_just_before_return_LOOPS (Failed) 78 - regression/undominated_variable_from_conditional_barrier_handling_LOOPS (Failed) 82 - regression/setting_a_buffer_argument_to_NULL_causes_a_segfault (Failed) 83 - regression/clSetKernelArg_overwriting_the_previous_kernel's_args (Failed) 85 - regression/case_with_multiple_variable_length_loops_and_a_barrier_in_one (Failed) Errors while running CTest Thanks! -- sh...@me... GPG public key ID : B517C4C8 |
From: Michal B. (TAU) <mic...@tu...> - 2020-07-06 19:41:46
|
Hello, what kind of "ordinary functions" do you have in mind ? are you talking about functions found in glibc, or your own code ? OpenCL has defined restrictions, described e.g. here: https://www.khronos.org/registry/OpenCL//sdk/2.2/docs/man/html/restrictions.html In particular: "Unless defined in the OpenCL specification, the library functions, macros, types, and constants defined in the C99 standard headers assert.h, ctype.h, complex.h, errno.h, fenv.h, float.h, inttypes.h, limits.h, locale.h, setjmp.h, signal.h, stdarg.h, stdio.h, stdlib.h, string.h, tgmath.h, time.h, wchar.h and wctype.h are not available and cannot be included by a program" ... so none of the functions from those headers can be called in OpenCL. There is printf() and a huge math function library, but other than that, the answer is negative. Regards, -- mb ________________________________ From: mashilamani sambasivam <kan...@gm...> Sent: Monday, July 6, 2020 9:16 PM To: poc...@li... <poc...@li...> Subject: [pocl-devel] calling ordinary C functions from kernel functions in opencl Hi, I am new to opencl. I am trying to port huge amount of C code to run on GPU with minimum modification to original C code. In that direction, I am trying to call ordinary C functions from my kernel functions. I want to know if that is possible with opencl 1.2 which you have implemented. Assume that I am taking care that each kernel has its own address space, its own stack etc which dont clash with other kernels. I have NVIDIA GTX1060 6GB. Thanks much, mani PS> I have tried in openmp and failed. In openmp, it is impossible to call ordinary functions from a function which is executing on "target" device. |