Hello, It is possible that I will see some significant render speed improvements in Blender3d if I can persuade it to talk to my GPU. On the other hand, I am on a laptop with not a great GPU so all this effort might be fruitless, but I thought I would give it a try... So I installed Beignet, ran Blender with OpenCL support enabled, selected GPU computation, hit render... and it very quickly crashed with a dump to the command line that looked like this : [arpie@max ~]$ CYCLES_OPENCL_TEST=true blender Read new prefs: /home/arpie/.config/blender/2.73/config/userpref.blend Device init succes Compiling OpenCL kernel ... <premain>: CommandLine Error: Option 'slp-vectorize-hor-store' registered more than once! <premain>: CommandLine Error: Option 'slp-vectorize-hor' registered more than once! <premain>: CommandLine Error: Option 'slp-threshold' registered more than once! ... [approx 50 similar lines snipped] ... <premain>: CommandLine Error: Option 'inlinehint-threshold' registered more than once! <premain>: CommandLine Error: Option 'inline-threshold' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options -- I only have one graphics card and the only file present in /etc/OpenCL/vendors/ is, as you might expect, intel-beignet.icd The output from utest_run means very little to me but will hopefully give you all the relevant information about my machine : [arpie@max utests]$ ./utest_run platform number 1 platform_profile "FULL_PROFILE" platform_name "Intel Gen OCL Driver" platform_vendor "Intel" platform_version "OpenCL 1.2 beignet 1.0 (git-bec3c00)" platform_extensions "cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_icd" device_profile "FULL_PROFILE" device_name "Intel(R) HD Graphics Haswell GT2 Mobile" device_vendor "Intel" device_version "OpenCL 1.2 beignet 1.0 (git-bec3c00)" device_extensions "cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_icd" device_opencl_c_version "OpenCL C 1.2 beignet 1.0 (git-bec3c00)" 21 image formats are supported It reports 18 failed tests, but that is a Known Issue on Intel 4th gen GPUs and seems unrelated to this issue. -- Other useful info includes : OS: Arch Linux 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015 x86_64 GNU/Linux Blender version 2.73 Beignet version 1.0.1 GPU : 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) -- I have also successfully run this script : https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=beignet_test.py;att=1;bug=767148 The output is as follows : beignet_test.py:15: RuntimeWarning: invalid value encountered in sqrt b=np.cos(a)+np.sin(a)+np.sqrt(a) beignet_test.py:18: RuntimeWarning: invalid value encountered in sqrt b=np.cos(a)+np.sin(a)+np.sqrt(a) cossinsqrt numpy time 0.047619047619047616 kernel time 0.0013010668748373666 error 6.34193e-05 mul19 numpy time 0.02976190476190476 kernel time 0.0014619883040935672 error 1.17392e-38 -- That is about all the info I can think to report. Please let me know if I can run any further tests. Equally, this could be a Blender bug... but I thought it seemed more likely to be Beignet. If you think otherwise, please let me know and I will submit a report to the Blender team. Thanks in advance, Russell
You can try the following patch which should fix the build problem. But you may meet other problems after that if you continue to try blender, and you are welcome to file new bugs if so. Thanks. commit a9366a0e3b5f4bc1e9907ec165aecf741aa66a7c Author: Zhigang Gong <zhigang.gong@intel.com> Date: Fri Feb 27 15:52:59 2015 +0800 Build: use -Bsymbolic to fix conflicts with other LLVM users. As there may be some other LLVM users such as mesa, and they may link to different LLVM library. To avoid such type of conflicts, we use -Bsymbolic to disable the symbol preemption. This patch should fix the build bug at: https://bugs.freedesktop.org/show_bug.cgi?id=89325 Signed-off-by: Zhigang Gong <zhigang.gong@intel.com> diff --git a/CMakeLists.txt b/CMakeLists.txt index b731973..88ff872 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -86,7 +86,7 @@ ELSE (USE_STANDALONE_GBE_COMPILER STREQUAL "true") ENDIF (USE_STANDALONE_GBE_COMPILER STREQUAL "true") -set (CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined ${LLVM_LDFLAGS}") +set (CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-Bsymbolic -Wl,--no-undefined ${LLVM_LDFLAGS}") # XLib Find_Package(X11)
Thank you very much for the fast response. You were quite right - that patch has fixed the OpenCL compilation issue but there is a crash when it runs. Unfortunately, I don't have much to give you for debugging it! The following is the output I see on the command line when I try to render the default blender scene (just a cube) using the Cycles Renderer : [arpie@max build]$ CYCLES_OPENCL_TEST=true blender Read new prefs: /home/arpie/.config/blender/2.73/config/userpref.blend Device init succes Compiling OpenCL kernel ... %132 = load i32 addrspace(2)* %131, align 4, !tbaa !54 Illegal pointer which is not from a valid memory space. Aborting... Should I report this as a new bug? Is there any way I can get more verbose output to help track it down? Equally, do you think it is too ambitious to be trying to get this to work at all? I suspect the speed up I will get will be minimal (if any at all), as I am not exactly using a high-spec GPU. In fact, that might be the cause of the crash - not enough memory available on the GPU? But that is just a naive guess! I should stop speculating and leave it to the experts... Russell
(In reply to Russell Palmer from comment #2) > Thank you very much for the fast response. You were quite right - that > patch has fixed the OpenCL compilation issue but there is a crash when it > runs. Unfortunately, I don't have much to give you for debugging it! The > following is the output I see on the command line when I try to render the > default blender scene (just a cube) using the Cycles Renderer : > > [arpie@max build]$ CYCLES_OPENCL_TEST=true blender > Read new prefs: /home/arpie/.config/blender/2.73/config/userpref.blend > Device init succes > Compiling OpenCL kernel ... > %132 = load i32 addrspace(2)* %131, align 4, !tbaa !54 > Illegal pointer which is not from a valid memory space. > Aborting... I can't reproduce this. Could you tell me the LLVM/Clang version you are using? You can get it by execute: llvm-config --version. > > > Should I report this as a new bug? It's better to file new bug for a different symptom. So I change the subject of this bug report to accurate indicate the original issue you met. > > Is there any way I can get more verbose output to help track it down? > > Equally, do you think it is too ambitious to be trying to get this to work > at all? I suspect the speed up I will get will be minimal (if any at all), > as I am not exactly using a high-spec GPU. In fact, that might be the cause > of the crash - not enough memory available on the GPU? But that is just a > naive guess! I should stop speculating and leave it to the experts... To support blender's CYCLE engine is a little bit ambitious due to its very large computing kernel. But we will continue to improve beignet to support it eventually. Don't know which GPU are you using, if you are using a HSW GT3, then if we can get blender work with beignet, it should give noticeable performance boost. If you are using IVB GT1 or HSW GT1, then it may not worth to enable GPU acceleration. > > Russell
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.