cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Meteorhead
Challenger

CodeXL fails to find AMD OpenCL runtime (among other things)

Hi!

CodeXL hasn't been of much help since it got released, since I haven't seen the debugging part of it work a single time. I reported bugs in the installer, at least those went away, but the bigger problem, that renders the tool useless persists. When I open a project in VS2012 (any project, not just those that I wish to debug) it CodeXL pops up an error message saying: Could not load project file. Jolly good! Who cares? Of course you couldn't find one, because there is no CodeXL project file just yet. However, you shouldn't have touched it anyway, since how on Earth would VS know if this is an OpenCL project, or an ordinary CPU application?

Then, when I would want to do some debugging, it just pops open a command console and closes it immediately. Very informative. The when I would ask it to "Draw step", (I got no idea what that is) it tells me, I have no AMD GPU installed on my system. I say "ahha! That's the problem". I check system info inside CodeXL, and under OpenCL platforms, there is really no AMD platform available, it only sees the Intel runtime installed. I say to myself: maybe they collide in some way, let's uninstall the Intel OpenCL runtime. After that, nothing appears. clinfo.exe reports my AMD platform allright, but CodeXL does not see it. (Boy, what must be going on under the hood if practically ANY command console sees my GPUs, but not the SDK...)

Tested platform: Windows 8 64-bit, VS2012, Catalyst 13.6 Beta 2 (?)

Beta 2 is it? I had serious compiler issues (which I will report in the OpenCL section of Places) so I tried to revert my Beta 1 driver to 13.4. I used the Catalyst Uninstall-tool provided by AMD. It wrecked my computer real nice, since it did uninstall everything that was AMD, but even many Bluetooth drivers (they have nothing to do with each other, my notebook is an Intel platform), and all installers failed to install the HDMI Audio and Display Driver modules. AWESOME! System restore to the rescue!

Everything's fine, I got Beta 1 installed (presumably, unfortunately Catalyst's Info section does not hold a string saying "Catalyst 13.6" or anything, just version numbers, and gosh... why else would I open CCC Info section for if not to check the package version? Yes, the API version numbers are nice, but a simple string saying "Catalyst 13.6 Beta 1" would be a lot more informative to the casual end user. (Yes, I refuse to dive into the release notes of the drivers, and make the version number checks by hand) Beta 1 >> Beta 2. Sounds easy enough. Not. Beta 2 installer fails to install HDMI Audio and Display Driver that same way. Hoorray! (Plus, I have no idea why CCC fails to mention OpenCL runtime version, if it is so obsessed with version numbers. Maybe because that one at least would interest me, whether runtime changes have occured since the last driver or not.)

I attached system info reported by CodeXL standalone app, and a screenshot of clinfo.exe, CCC system info and CodeXL seeing no platforms.

Cheers,

Máté

0 Likes
5 Replies
dorono
Staff

Hi Máté,

Thank you for the detailed report and the lively description. I feel your frustration and hope that we can help.

We'll investigate the CodeXL issues and forward the driver related issues to the driver group.

While we investigate, I have a quick experiment I'd like you to try: log out of your Windows session, and login with a user name that contains only standard ASCII characters, i.e. no á, é or any of their annotated friends. Try to debug and see if you fare better.

Hi Doron!

I have tried what you suggested, created a local "Test" user, and the "Unable to load project file" problem no longer occurs, but it still fails to find the AMD runtime. So Unicode support would be much appreciated, as Windows 8 creates user name from my real name, which I have little control over.

The issue with the runtime is quite mysterious. I will try fiddling around with my environment, maybe something's conflicting in my PATH with CodeXL.

Also, I do not know how hard it is to make installers, but it is quite funny, that AMD has Catalyst Install Manager, a seperate application to handle solely their own SW, they have a seperate Uninstall Tool, and things still don't work. I install all AMD related stuff (at least the ones I'm asked about in full ASCII paths), so that cannot be an issue. It's as if driver uninstallation under Windows would be an unsolvable problem. (I understand Wnidows keeps backup of all drivers under SysWoW, but hey... it's been a while since AMD is making drivers)

0 Likes


Let me bump this thread with some new info.


I have checked the new version of CodeXL, and sadly there is no difference with it. I have created a new user (similar like last time), therefore my environment and PATH variables are as clean as they can get. New user, same project, once opened there is no error message, but debugging still does not work I press CodeXL debugging, and a command line window pops up, and closes immediately after, no error messages, nothing.


This time around with my own user and the test user, both see all OpenCL implementations (Intel and AMD both). I have seen under my own user, that the path to store logs and stuff for CodeXL was C:\Users\MTFEREN~1\... which clearly shows that it does not speak Unicode. I changed this to properly show C:\Users\MátéFerenc\... and also tried with a path not containing Unicode characters, but nothing seemed to work.


I must say I'm very disappointed in CodeXL. Prior to AMD's acquisition, gDEBugger worked perfectly. Since CodeXL, I have had no luck in getting debugging working. (And since some time, not even profiling)


I have a segmentation fault somewhere in my code which I am practically unable to detect. If I place if(I_AM_THE_DEBUGGED_THREAD){...} clauses all over my code, so only a single thread executes from all the launched threads (but I keep all mem_fences and barriers outside these clauses, so basically all of the threads but one do nothing, just do some sync instructions, and even this way, my app crashes in the middle of a printf statement of the sole normally executing thread. This is virtually impossible to debug. I would like to get a step-by-step debug working to see where the others crash my app.

0 Likes
Meteorhead
Challenger

Hello!

I would like to yet again bump this thread, because CodeXL 1.4 still does not solve my issue. When I open a project with Visual Studio 2013, no CodeXL project is generated. Luckily, since CodeXL became a little more verbose, I could find the reason for it not doing so. It is not the problem of whether the project contains Unicode characters or not, neither it is whether the CodeXL intallation path contains Unicode characters or not. CodeXL prints a debug message, that it's trying to use my Documents dir as a temporary directory, and MY NAME STILL HAS UNICODE CHARACTERS IN IT, thus Windows will still create this kind of %HOME% directory, regardless of how much pain it causes me due to programs not handling it correctly.

GPU Profiling gives me:

Failed to open file : C:/Users/MAMD CodeXL GPU Profiler V3.1.5724 is Enabled

Failed to open file : C:/Users/MAMD CodeXL GPU Profiler Kernel occupancy module is enabled

Naturally, it's trying to access C:/Users/MátéFerenc/AMD CodeXL... which it cannot.

Please, tell me how to hotfix it locally (there are HEAPS of registriy setting mentioning CodeXL, and I have not found one that specifies this temp dir), or issue a hotfix to the installer. This has been an issue for over a year now, CodeXL not handling Unicode paths normally. And I still have no control over my %HOME% dir on Windows. Or shall I change the %HOME% Env Var everytime I want to work with CodeXL?

0 Likes
Meteorhead
Challenger

I am glad to announce that the new version (1.5.6571) of CodeXL issued just now still suffers from this bug. Kick me in the hoppledoodledoo fantastic. Let's wait another 6 months.

0 Likes