FreeBSD lacks in prefessional OpenCL/GPGPU support. Apart from the lack of suitable driver support from the GPU vendors, OpenCL also provides support for tha CPU as a "native" target. To provide even FreeBSD users, develeopers and scientists to develop software for OpenCL 1.2, it is necessary to have a working library to start with. The project "POCL", Portable OpenCL, provides via LLVM backend such a library for at least the "native" CPU target, as their website states: "Portable OpenCL is an open source implementation of the OpenCL standard which can be easily adapted for new targets. One of the goals of the project is improving performance portability of OpenCL programs, avoiding the need for target-dependent manual optimizations. A "native" target is included, which allows running OpenCL kernels on the host (CPU)." Source: https://launchpad.net/pocl Fix: Patch attached with submission follows: How-To-Repeat: This port has been successfully compiled on a most recent FreeBSD 10.0-CURRENT/amd64 system which has been completely compiled with CLANG 3.2 and LLVM 3.2 installed from ports devel/llvm-devel. The port also has been successfully compiled and installed on FreeBSD 9.1-PRE/amd64, also completely compiled with the CLANG (v 3.1) aboard and LLVM 3.1 installed from the port devel/llvm. The usefulness hasn't been approved, nor did I do benchmarks for the "native" CPU target. I hope this [roject, due to its LLVM backend, could gain more assistance and more attention.
Responsible Changed From-To: freebsd-ports-bugs->mva I'll take it.
State Changed From-To: open->feedback As discussed via mail, version 0.7.0 of pocl seems to be released. Do you mind to update the port? Thanks.
Hi, On, Mon May 13, 2013, O. Hartmann wrote: [...] > Hello, > > as it has been published in the POCL mailing list, version 0.8 is on the > brink and compiling on FreeBSD due to a better support. There are some > issue I try to handle with my limited knowledge, but I'd like to update > much more to 0.8 than 0.7. > > There is also still a problem in compiling/configuring "ocl-icd", which > is an external package found at > > https://forge.imag.fr/projects/ocl-icd/ > > which we should have in conjunction with POCL. > > Since POCL gets more attention, even by AMD. > > I will update the proposed port for 0.8 as it gets released. Is that all > right? this is perfectly fine with me. I'll set this on hold once more then. Cheers Marcus
State Changed From-To: feedback->suspended Waiting for the 0.8 release
State Changed From-To: suspended->open Feedback received.
Is this PR still relevant?
(In reply to Carlo Strub from comment #6) > Is this PR still relevant? Yes, it is. This is still the only proper way of getting full OpenCL support on FreeBSD. (freeocl is lacking a lot of functionality and we don't even have to talk about support from Nvidia/Intel/AMD ...) Also, the last patch from ohartman that was attached here https://www.freebsd.org/cgi/query-pr.cgi?pr=171914 seems to have been lost in the migration? This was for pocl 0.8 and it worked pretty well. I'm wondering why this was never added to ports?
Due to time constraints and the lack in a deeper knowledge of POCL the ports is slowed down. My personal framework is at POCL-0.10, but with FreeBSD, there is a serious code generation bug in FreeBSD's LLVM/CLANG 3.4.2 (from ports). This happens not to happen on Core2Duo architecures, but on every CPU architecture > C2D, several tests fail and it seems to be obvious that only FreeBSD has this bug. Linux doesn't. It may be due to my personal setup (I use always some strong optimizations on the compiler). Upstream is informed, but will be fixed earliest in POCL-0.11. I have no equipment to build ports automatically for several OS types, like 9.3-STABLE, 10-STABLE etc., so I'm stuck with 11-CURRENT for now. This has been shown as a problem in the past. I will emmit the new SHAR the next days - along with two ports for ICD (ocl-icd and khronos-icd). For short: I think it is relevant, but my time is really limited. Regards, Oliver
Thanks for your feedback. Let's put it to "open".
Created attachment 151645 [details] *very* rough port update to the recent v0.10 release A bit late to the party, but I just checked with devel/llvm35 on their trunk (the latest release on their side is 0.10 supposed to work with llvm35 and fixing issue #123 ohartmann opened) and it does compile out of the box with the following configure: ./configure --disable-icd CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib/" LLVM_CONFIG="/usr/local/llvm35/bin/llvm-config" With the mesa10.4 development branch now featuring a Clover port, it would make sense IMHO to get this into the tree and also look into resolving the upcoming ICD challenges with the guys responsible there. Bottom line: I may be able to spare a few cycles on this, how can I help? Find attached a (probably violating close to a thousand port rules) adjustment of the original port to v0.10. It does however compile... Please note that I removed the options for gcc vs llvm and hardwired llvm34. I feel this is in line with the Mesa ports. Personally, I may consider offering llvm34 vs llvm35 but that is another story, I suppose.
Created attachment 151648 [details] improved Makefile
Sorry for the late response. I already have/had a "compiling" port infrastructure for 0.10, but there was a serious bug with LLVM/CLANG 3.4 only occuring in FreeBSD, not on any Linux platform. For the ICD: I also about to propose two ports for ICD: devel/ocl-icd (at the moment version 2.2.3) and devel/opencl-icd (which is a simple port of Khronos' suggestion of their ICD). Please give me a bit time to make updated proposals ready. I messed up a bit with the requistes and the porting of POCL 0.10 that way, as POCL definitely uses its own CL header files - still at OpenCL 1.2. The port does get into a conflict while compiling using port devel/opencl, which provides now headers for OpenCL 2.0. I also appreciate any help. Thanks in advance, Oliver
If you refer to #123 on github you opened: that one's solved according to the authors (see: https://github.com/pocl/pocl/issues/123). Indeed, I can confirm that the tests pass on my Ivy CPU using the latest shar-archive I attached and devel/llvm34 (disclaimer: as you also noted there, their testsuite by default skips a lot of tests). Concerning the ICD and header files: I believe it would be worthwhile to contact the x11@ team what they envision now that we finally seem to be getting clover. :-) Well, let me know if/how I can help. I have a vivid interest in being able to do my OpenCL development on FBSD instead of Linux. Poking mva@: are you still up for getting this into the tree? That'll be awesome!
We currently working on making ports for Clover (Mesa based OpenCL for radeon cards) and Beignet (OpenCL for intel cards) (based on llvm35 since I read that llvm34 has some regressions concerning OpenCL). The plan is to put these into lang/ since it more of a language to talk to the GPU's then anything else. Apart from the fact that devel/ is already very crowded. I think the software (CPU) implimentations should be moved to lang/ too, Hartman what are your thoughs on this proposed move? I haven't looked closely into ocl-icd and opencl-icd. I can see why we might want to provide a offical khornos port but isn't it beter to just have one so there is no possible conflict between the two?
Created attachment 156233 [details] POCL 0.11-SHAR
Lost the comment, sorry ... Attached you'll find another SHAR targetting POCL 0.11. There is still an issue in test case 22, which is triggered due to the fact that FreeBSD names the Intel 64 bit architecture amd64 and in Linux, it is named x86_64. I'm on this but due to duties it will take a while.
Created attachment 169196 [details] POCL-0.13 released, utilizing OpenCL 2.0 and LLVM 3.8.0 PCOL-0.13 has been released, this is a cleanup of the previous attempts, using devel/opencl in its OCL 2.1 incarnation (not approved yet).
FWIW, I am using pocl 0.13 to develop OpenCL code and it works well. I have used prior versions with the same success. Unlike freeocl (which is in the ports collection), this integrates nicely with ocl-icd loader and the rest of the OpenCL infrastructure we recently established. This port would be a very good addition to the ports collection to allow wider adaption of OpenCL in FreeBSD.
Any progress on this port? I noticed that for freebsd users it is necessary to compile the OpenCL application with -pthread in CFLAGS and CXXFLAGS (not the port itself but the application a user writes). Should this be mentioned in a pkg-message? Seen here: http://portablecl.org/docs/html/faq.html?highlight=freebsd
Created attachment 174353 [details] pocl.diff (new port as diff as recommended by porter's handbook) This patch is a DIFF against ports/devel and should give you the framework to install and use POCL. I have not tested this patch thoroughly and it has been successfully working on FreeBSD 11-CURRENT and now on 12-CURRENT. Some fixes has been introduced compared to my initial submits:
(In reply to ohartman from comment #20) (Accident with the return key ..., sorry) 1) With change from 11-RC to 12-CURRENT, I realized that in pkg-plist, the line according to %%DATADIR%%/kernel-amd64-portbld-freebsd%%OSREL%%.bc has to be fixed introducing the %%OSREL%% substitution. 2) Thanks to @David Kalliecharan (comment 19) I added a a comment in pkg-message according to the developer's recommendation. 3) With >= LLVM 3.8.1 it seems that some strict C++11 checking was needed (followed the bug report on GIThub: https://github.com/pocl/pocl/issues/365. By adding CONFIGURE_ARGS=CLANGXX_FLAGS=-std=gnu++11, a compilation error could be avoided. I checked also CONFIGURE_ARGS=CLANGXX_FLAGS=-std=c++11, which I use now in my private port, which makes the port compile properly. Latter one makes me feel more FreeBSDish/CLANGish - sorry about the misuse of the language (English).
Please also have a look at new devel/ocl-icd patch: Bug 212363 and new devel/opencl patch: Bug 212362
Any chance this will *ever* hit the ports tree? ;-) This port is *sorely* needed. Any of the small "nits" that might accompany it, can be more easily sorted out having more eyes, and helping hands available for it once it's in the tree. No? :-) Thanks ohartman, and everyone else who've helped to get this in the tree! --Chris
Since I have been recently made aware by one of the "upper class" maintainer/comitter of the ports tree, that the port firt needs a proper test via poudriere and portlint to keep the quality of the tree up, I need first to test the port whether it builds correctly under "fresh and vanilla" conditions. poudriere and jails are new to me and although setup is relatively easy, there are several pitfalls in custom setups and then someone, like me, with limited knowledge runs into problems. poudriere and jails put another level of efforts and labor to the portingwork. I will do my best to test the port within a poudriere environment! Stay tuned. Regards, Oliver
Testing the proposed port devel/pocl via poudriere results in an error I do not understand, since in a fresh vanilla REAL installation this error doesn't occur. The log shows : [...] ---End make.conf--- =======================<phase: check-sanity >============================ /!\ pocl-0.13: Makefile warnings, please consider fixing /!\ It looks like the libhwloc.so:/usr/ports/devel/hwloc depends line has an absolute port origin, make sure to remove ${PORTSDIR}/ from it. ===> License GPLv3 accepted by the user ===> Found saved configuration for pocl-0.13 =========================================================================== =======================<phase: pkg-depends >============================ ===> pocl-0.13 depends on file: /usr/local/include/CL/cl.h - not found ===> Installing existing package /packages/All/opencl-2.1.txz /usr/ports/Mk/Scripts/do-depends.sh: /usr/local/sbin/pkg-static: not found *** Error code 127 Stop. make: stopped in /usr/ports/devel/pocl [...] The environment has been enriched with the patches for port devel/opencl ( PR 212362 ) and devel/ocl-icd ( PR 212363 ) - both ports build well without error. I do not know what this error shown above menas - maybe someone has an idea. I guess the port devel/opencl installs the header files into a folder not found by the poudriere framework. Or its a bug in poudriere.
Currently taking a look at this port. When I get it working I will post a new diff for you to approve.
Created attachment 175988 [details] Current pocl 0.13 without the sysinfo patch I haven't finished the sysinfo patch. Mind you I'm trying to do it in such a way that it is upstreamable but maybe we should just go for making it work and worry about upstream later.
I have added an altered version of this port to the FreeBSDDesktop bring-up ports repository at https://github.com/FreeBSDDesktop/freebsd-ports-graphics (xserver-mesa-next branch). Please file pull requests there if you want things changed, we hope to get to a converged port that can then be added to upstream soon.
A commit references this bug: Author: kwm Date: Mon Nov 21 14:36:52 UTC 2016 New revision: 426722 URL: https://svnweb.freebsd.org/changeset/ports/426722 Log: Add pocl. Portable OpenCL aims to be an efficient open source (MIT-licensed) implementation of the OpenCL 1.2 standard. pocl uses Clang as an OpenCL C frontend and LLVM for the kernel compiler implementation, and as a portability layer. Thus, if your desired target has an LLVM backend, it should be able to get OpenCL support easily by using pocl. PR: 171914 Submitted by: O.Hartmann <ohartmann@walstatt.org> (based on) Changes: head/lang/Makefile head/lang/pocl/ head/lang/pocl/Makefile head/lang/pocl/distinfo head/lang/pocl/files/ head/lang/pocl/files/patch-Makefile.in head/lang/pocl/files/patch-lib_CL_devices_cpuinfo.c head/lang/pocl/files/patch-scripts_Makefile.in head/lang/pocl/pkg-descr head/lang/pocl/pkg-message head/lang/pocl/pkg-plist
Committed thanks! I put it in lang/ so it together with all the other opencl "libraries".