| Priority | medium |
|---|---|
| Bug ID | 82717 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | OpenCL support for mandelbulber-opencl |
| Severity | normal |
| Classification | Unclassified |
| OS | All |
| Reporter | haagch@frickel.club |
| Hardware | Other |
| Status | NEW |
| Version | git |
| Component | Drivers/Gallium/radeonsi |
| Product | Mesa |
Website of the program here: https://sites.google.com/site/mandelbulber/ (Watch out, it uses a weird install script) Start it, go to the OpenCL tab and try to enable OpenCL. A few things that probably need to be addressed. I applied some workarounds to see them all and I don't even know if the OpenCL programs would work after removing all of that stuff. Problem 1: OpenCL Build log: ERROR: Program::build() (-43) That's because of the build paramater -cl-denorms-are-zero that is hardcoded in the source code of mandelbulber. Workarodund 1: sed -i 's/-cl-denorms-are-zero / /g' src/cl_support.cpp Problem 2: OpenCL Build log: input.cl:34:1: error: OpenCL does not support the 'static' storage class specifier So that's not valid in OpenCL 1.1, but for the sake of getting it to "just compile" at least: Workaround 2: for i in /usr/share/mandelbulber/cl/*; do sed -i "s/static //g" $i; done Problem 3: OpenCL Build log: input.cl:323:10: error: cannot combine with previous 'type-name' declaration specifier input.cl:323:15: error: expected identifier or '(' input.cl:324:8: error: expected identifier or '(' input.cl:325:32: error: expected _expression_ � (WTF is random binary data doing here?) That's a weird one that seems to come from whatever clang does. I think clang thinks that "half" is already defined in the OpenCL kernels. Not sure if this is intended. Workaround 3: for i in /usr/share/mandelbulber/cl/*; do sed -i "s/half /halfFOO /g" $i; done for i in /usr/share/mandelbulber/cl/*; do sed -i "s/half)/halfFOO)/g" $i; done Problem 4: OpenCL Build log: �}� OpenCL program built done OpenCL kernel opened OpenCL workgroup size: 256 OpenCL Job size: 480256 terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc I don't think the crash itself is the fault of mesa opencl, because the backtrace looks like this: #0 0x00007fd1154e2d67 in raise () from /usr/lib/libc.so.6 #1 0x00007fd1154e4118 in abort () from /usr/lib/libc.so.6 #2 0x00007fd115dd81f5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6 #3 0x00007fd115dd6076 in ?? () from /usr/lib/libstdc++.so.6 #4 0x00007fd115dd60c1 in std::terminate() () from /usr/lib/libstdc++.so.6 #5 0x00007fd115dd62d8 in __cxa_throw () from /usr/lib/libstdc++.so.6 #6 0x00007fd115dd6869 in operator new(unsigned long) () from /usr/lib/libstdc++.so.6 #7 0x00007fd115dd68c9 in operator new[](unsigned long) () from /usr/lib/libstdc++.so.6 #8 0x00000000004a3683 in CclSupport::InitFractal (this=0x207e200) at ../src/cl_support.cpp:451 #9 0x000000000042cffb in ChangedOpenClEnabled (widget=0x22bdd60, data="" at ../src/callbacks.cpp:2896 #10 0x00007fd11673b3d8 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #11 0x00007fd11674cd5d in ?? () from /usr/lib/libgobject-2.0.so.0 But why is there random binary data in the OpenCL build log? llvm-svn 215809 libclc-git 165.20140816 opencl-headers12 1:1.2.r26859 (not sure if relevant) mesa git from today radeon 7970M pitcairn
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
