On a couple of software where OpenCL is enabled, I run recently into a serious problem (also on lang/pocl). The OpenCL code quits execution immediately with the error similar to that shown below. Searching the net for this error reveals bug reports reaching as far as early 2016 and the problem is considered to be a LLVM bug. I have no clue how to fix this or work around, so I report this here. From POCL's github, I got this report with no satisfying result: https://github.com/pocl/pocl/issues/474 [...] X server found. dri2 connection failed! Device open failed, aborting... : CommandLine Error: Option 'enable-value-profiling' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Nothing to output ! [...] As far as I can understand, the problem is caused by LLVM in case several ICDs register to the very same LLVM backend.
While I haven't had any opencl build issues, I have had no success getting any opencl code to work, even non-blender. I left the opencl option available in graphics/opensubdiv but deliberatly disabled cycles opensubdiv support from using opencl as it naively assumes opensubdiv has opencl support. Are you building opensubdiv with opencl enabled? Blender can use opencl within the compositor as well as in cycles rendering and opensubdiv, could those multiple options be the cause of the clash? Not sure I can offer any help here, but will accept any changes needed to make opencl work.
*** Bug 223844 has been marked as a duplicate of this bug. ***
Can you re-test this with the last patch in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224584 please? This one uses LLVM 5.0 and I'm not experiencing this issue.
The problem is still present with LLVM 7.0 as for its predecessors. I files a PR (PR 233495) to gather all the issues and relate them to one spot. The issue seems to spread more and more as OpenCL platforms with LLVM backends become consistently linked against the same LLVM backend.
Still relevant or can we close this?
closed case.