Created attachment 478310 [details] kernel .config I was very exited to see that now there is a possibility to run OpenCL without ditching the open source X11 stack completely. However it unfortunately does not work for me at the moment. Running gentoo-sources-4.11.7, Xorg 1.18.4, libdrm-2.4.80, xf86-video-amdgpu-1.3.0. Binaries just segfault when I run them (clinfo, xmr-stak-amd): coredumpctl gdb Journal file /var/log/journal/0222eeef96646469f9310bc058b6e83d/system@00054a20343cdc68-5c17073313466bd4.journal~ is truncated, ignoring file. PID: 897 (xmr-stak-amd) UID: 1000 (ef) GID: 1000 (ef) Signal: 11 (SEGV) Timestamp: Thu 2017-06-29 01:34:02 CEST (3s ago) Command Line: ./xmr-stak-amd Executable: /home/ef/xmr/gpu/xmr-stak-amd Control Group: /user.slice/user-1000.slice/session-c3.scope Unit: session-c3.scope Slice: user-1000.slice Session: c3 Owner UID: 1000 (ef) Boot ID: d4e6b863f0e4401480e27ce1f22583ed Machine ID: 0222eeef96646469f9310bc058b6e83d Hostname: supah Storage: /var/lib/systemd/coredump/core.xmr-stak-amd.1000.d4e6b863f0e4401480e27ce1f22583ed.897.1498692842000000.lz4 Message: Process 897 (xmr-stak-amd) of user 1000 dumped core. GNU gdb (Gentoo 8.0 vanilla) 8.0 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/ef/xmr/gpu/xmr-stak-amd...(no debugging symbols found)...done. [New LWP 897] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `./xmr-stak-amd'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000000000 in ?? () Running the full closed source binary on the same machine (with kernel 4.9.34
Created attachment 478312 [details] emerge --info
Created attachment 478314 [details] dmesg
Unfortunately I have been unable to reproduce the problem on my RX 470. clinfo, LuxMark and darktable all work as they should, and xmr-stak-amd doesn't segfault (although that particular bit might not mean anything because with no valid config file found, it simply exits right away). What GPU have you got? Furthermore, unfortunately your original post seems to have been truncated but is it correct that you have got the whole AMDGPU-Pro stack installed on your machine as well?
It's not only xmr-stak-amd which segfaults, but also other stuff like clinfo. My GPU is a MSI Radeon RX470 Gaming X 8G. You are correct that the whole AMDGPU-Pro stack is installed too. But I boot into a different kernel (means no amdgpu-pro module compiled in), and did eselect opencl ocl-icd and eselect opengl mesa before booting into the dev-libs/amdgpu-pro-opencl usecase. Is this still not enough and I have to remove the AMDGPU-Pro stack completely?
(In reply to ernsteiswuerfel from comment #4) > It's not only xmr-stak-amd which segfaults, but also other stuff like > clinfo. I know, and like I said in my previous comment I can successfully use other programs - clinfo included. I've singled out xmr-stak-amd because unlike the others, I haven't had that one configured so it probably never got to the stage when it tried to actually do anything on the GPU. > You are correct that the whole AMDGPU-Pro stack is installed too. But I boot > into a different kernel (means no amdgpu-pro module compiled in), and did > eselect opencl ocl-icd and eselect opengl mesa before booting into the > dev-libs/amdgpu-pro-opencl usecase. Is this still not enough and I have to > remove the AMDGPU-Pro stack completely? Chances are this is indeed necessary. AMDGPU-Pro as a whole is not in Gentoo so I do not know how exactly it has been set up on your machine, that said chances are there still ARE some interactions between AMDGPU-Pro, dev-libs/amdgpu-pro-opencl (which is a) a subset of AMDGPU-Pro, and b) a bit of hack) and the rest of the system. Come to think of it, it might make sense to add some warnings to amdgpu-pro-opencl clarifying the above. Anyway, you could try and see if removing AMDGPU-Pro helps but since you already have it up and running, personally I wouldn't bother and just keep using the full proprietary stack until RadeonOpenCompute - which already supports Polaris - has made it into Gentoo.
I used the very good guide at https://www2.warwick.ac.uk/fac/cross_fac/complexity/people/staff/delgenio/amdgpuprogentoo to get the AMDGPU-Pro stack running. I needed a 4.9.x kernel with this specific options and a downgrade to xorg-server-1.18.4. If I get enough time the next days/weeks I'll try to get dev-libs/amdgpu-pro-opencl running by removing the Pro-stack and adjusting my 4.11.x .config gradually to the options the guide suggests (and which are used in my 4.9.x kernel). I'll report back here if I succeed. Me too would prefer RadeonOpenCompute but I don't count on it making it into Gentoo any time soon. ;-)
Mkay, finally had the time to check this out... You were correct, having the whole AMDGPU-Pro stack installed next to dev-libs/amdgpu-pro-opencl was the source of the problem. Luckily it was also the only problem! After removing the whole AMDGPU-Pro stack, re-emerging ocl-icd and amdgpu-pro-opencl I was able to run OpenCL-programs again. Modifying my kernel config was not necessary. So I can live happy again. ;-) Thanks!
OK, thank you for the update! (Changing the resolution to WONTFIX because it's not that exactly the same set-up works for some people and doesn't work for others - the problem was interference with something installed from outside the official tree.)
Another thing, could you add amdgpu-pro-opencl as opencl provider in virtual/opencl?
