cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

florian1
Adept I

CodeXL does not detect Catalyst and GPU on latest debian.

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

0 Likes
1 Solution
florian1
Adept I

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.

View solution in original post

0 Likes
11 Replies
pinform
Staff

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

0 Likes
florian1
Adept I

Is this really the only place where I can hope for support or did I miss some place?

0 Likes
florian1
Adept I

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.

0 Likes

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.

0 Likes

There are actually 2 more important CodeXL logs in /tmp, Server and your logname.

What is your clinfo output?

0 Likes

clinfo does not list anything besides my cpu. I'll post the logs when I have access to the machine again.

0 Likes

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

0 Likes

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.

0 Likes

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.

0 Likes

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.

0 Likes

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.

0 Likes