I installed the debian package of CodeXL without problems. The gui loads without problems and I checked that the correct libgl is found by CodeXL.
However the log in the lower left corner says that neither my AMD GPU (R7 270X) nor the Catalyst driver where detected. Therefore many features are disabled. I am specifically interested in the Static analyzer and the GPU profiler.
I use the current fglrx-driver (15.9) package on an up to date Debian stretch system. I also tried earlier versions of fglrx (for example 14.9 and 15.7), but it makes no difference. Unfortunately the debian packages for the driver on the AMD website require ancient kernel versions (I use the standard 4.2 kernel in the Debian repository) and are generally problematic (I have not read a single report of anyone successfully using them on debian, the debian supplied ones are quite reliable).
How does CodeXL try to detect catalyst and the GPU? How can I fix it to detect my driver and GPU correctly?
Best regards,
Florian Uekermann
Solved! Go to Solution.
These two debug messages might be useful. I can't find the library anywhere, not even in AMDs .debs.
#DEBUG #0 #140687976528576 #osLoadModule #65 #Failed to load module. OS error is: /usr/lib64/libatiadlxy.so: cannot open shared object file: No such file or directory. Module = libatiadlxy
#ERROR #0 #140687976528576 #GetDriverVersionInfo #480 #Failed to extract driver version. Error code: 2
What does CodeXL do to extract the driver version?
Edit: The driver version problem seems to be a bug in the debian fglrx packages, which is fixed in the most recent version. The comments below remain valid and should be fixed in CodeXL and have to be taken care of manually by the user at the moment.
More comments:
-CodeXL should look in /usr/lib/x86_64-linux-gnu/ as well for all libraries it expects to be at /usr/lib64. Or it could just traverse the library paths.
-Setting the debug path in Tools-Options has no effect for me.
-the location of ldconfig is not necessarily in $PATH. You should probably add export PATH=$PATH:/sbin/:/bin/ to your CodeXL and CodeXLAnalyzer scripts. I get an error with CodeXLAnalyzer if I don't do that.
If you fix those I would expect the package to work even if people use the fglrx packages in the Debian and Ubuntu repositories.
Hi Florian,
Welcome!
I am white-listing you, so you can directly post in the relevant developer forum. I am also moving this post to the CodeXL forum, where you should receive useful replies from the experts.
--Prasad
Is this really the only place where I can hope for support or did I miss some place?
These two debug messages might be useful. I can't find the library anywhere, not even in AMDs .debs.
#DEBUG #0 #140687976528576 #osLoadModule #65 #Failed to load module. OS error is: /usr/lib64/libatiadlxy.so: cannot open shared object file: No such file or directory. Module = libatiadlxy
#ERROR #0 #140687976528576 #GetDriverVersionInfo #480 #Failed to extract driver version. Error code: 2
What does CodeXL do to extract the driver version?
Edit: The driver version problem seems to be a bug in the debian fglrx packages, which is fixed in the most recent version. The comments below remain valid and should be fixed in CodeXL and have to be taken care of manually by the user at the moment.
More comments:
-CodeXL should look in /usr/lib/x86_64-linux-gnu/ as well for all libraries it expects to be at /usr/lib64. Or it could just traverse the library paths.
-Setting the debug path in Tools-Options has no effect for me.
-the location of ldconfig is not necessarily in $PATH. You should probably add export PATH=$PATH:/sbin/:/bin/ to your CodeXL and CodeXLAnalyzer scripts. I get an error with CodeXLAnalyzer if I don't do that.
If you fix those I would expect the package to work even if people use the fglrx packages in the Debian and Ubuntu repositories.
Here is the full debug output after fixing manually what I could fix (Library paths, exports etc). There are a couple of errors I could not make any sense of myself and didn't mention in the previous message. (It might be nice to replace the tabs in the log by something else since tabs are unfortunately impossible to copy/paste in this forum without creating a table)
Edit: Since the name of the attached file was cause for confusion before: shared is the loginname of the user starting CodeXL.
There are actually 2 more important CodeXL logs in /tmp, Server and your logname.
What is your clinfo output?
clinfo does not list anything besides my cpu. I'll post the logs when I have access to the machine again.
Hmmm. I don't have libatiadlxy.so in my Linux system and CodeXL runs fine. Don't get errors about it in my logs, either. I don't know what that shared.log is, though.
If clinfo doesn't see your GPU, neither CodeXL will see it, nor your ocl compiler. Your are running your code over your CPU.
I had a similar problem smt ago. Solved it by reinstalling the sdk.
You have ocl setup problems. Need to solve those before proceeding 😞
HTH
The logfile I posted is the one with my loginname. The user is called shared.
There is no logfile called Server or anything similar.
The only other thing I could find is: /tmp/PwrBackendTrace.txt
Content: AMDTPwrProfileInitialize:1655- Return code: 0x80080011 counters 0
Yes, I know OpenCL does not work. I am using OpenGL and I can guarantee you that it runs on my GPU using fglrx. But since it might be related to the problem, I will try to fix OpenCL and see what happens.
In case someone can infer anything with that information:
strace tells me that the log message about not being able to detect the driver version happens right after some communication with the /tmp/.X11-unix/X0 socket.
Debian just got a second iteration of the latest driver packages and both CodeXL and OpenCL magically started working. The library paths and path variable problems in CodeXL remain and you have to fix them manually as described above.
That was no magic. As I told you, you had to reinstall catalyst driver (OK, I made a mistake and said SDK). First installation was bad. Even reinstalling the old driver would have worked.
No. The first Debian fglrx-driver 15.9 package has a (known, documented and fixed) OpenCl related bug. Which is the reason why the second version was published. I tried reinstalling the first version of the driver before reporting this. Magical means that I didn't look up the details and didn't want to speculate.
It may be true that the bug does not exist in AMDs Ubuntu packages, but those are very far behind in terms of kernel compatibility and therefore of no use to anyone on up-to-date linux distributions. Installing those breaks a lot more than just OpenCl and CodeXL.