AnsweredAssumed Answered

About my initial experience about CodeXL, and some ideas about AMD

Question asked by qtvali on Mar 11, 2015
Latest reply on Mar 19, 2015 by qtvali

So now I have successfully installed Chromium to make title of this new discussion editable, so that I can post it On newest KUbuntu, fresh install + Catalyst, I couldn't. This letter in general is full of bug reports and complaints, but I really hope I still have something to do with my new AMD computer, because it would be a little sad to tell my company that I failed and it's impossible to do programming with this computer. Because I was very serious about that I need just this one, and I waited 3 weeks instead of going to shop and buying any computer. And I spent a lots of time reading architecture documents of AMD, and the memory model and other arguments, which made me think that it's better than Intel even when the benchmarks seem to show the opposite. I used to love ATI over nVidia, but that was 10 years ago, later I haven't cared much.


As it's marked as a question, I also ask: what I really do need to get CodeXL to work on Ubuntu? The Teapot example is genuinely broken, as it shows OpenGL Teapot 2000-2500 FPS, but sorrily there is no smoke, no grid, no sign about anything from OpenCL. On Windows, I could resize the window (but I had to select drivers for both slots, random nVidia card, before first frame was rendered, to avoid crash, and out of two drivers/cards if I selected the second one, then it didn't actually select it). OpenGL canvas has a problem that if I maximize the window, the canvas size doesn't change, and if I normalize it back, the canvas is gone somewhere behind the window corner.


A thing worth noticing is my installation history of Linux on my new AMD computer, and all the things I noticed on the way:

- Last weeks I have been reading about AMD architecture. One thing worth noticing is that Google obviously does not support AMD - when I enter "CUDA", I get many things relevant to Intel graphics architecture, but when I was entering terms from AMD architecture documents, I got many irrelevant things, and it was much, much harder to get into topic and to get any understanding about what these terms mean. Sometimes Google was automatically searching some random stuff instead of the acronym or term I entered ("showing results about Y instead of X"), and usually the information was not relevant.

- After I got the computer, I decided to try Fedora Gnome. After going through several manuals about how to hack the AMD driver to work there, how to patch things, trying with and without patches etc., I had to give up - only thing what happened every time was that when I booted up, it stopped at the loading screen, and sorrily Fedora doesn't even have Ctrl+Alt+F1 key combination to get out of trouble.

- So I did still bet on Gnome 3, because there are some nice feats like Window Organizing and I want to try it. openSUSE is officially supported and installs with Gnome 3 by default, so I installed it - much slower boot and shutdown times and much less responsive OS, but anyway ..the error was about the same. It somehow installed, I needed to patch something and manually compile it, I think, from the files left from one-click-installer (I don't actually remember, that was yesterday), but then, when I finally got it, it didn't boot - I just told me that something went wrong, when I entered startx, and the automatic startx loading failed as well. I ran "aticonfig --initialize" and stuff, but nothing helped.

- Last night at 4 o'clock I had installed Ubuntu with Gnome, failed with it, and switched to KUbuntu with KDE. It had some fancy one-click-installer as well, but this didn't work; some messing around the packages made it clear that X Server was too new, so I ran "sudo apt-get install xorg-video-abi-15", which probably downgraded something, and after I was able to install the package from repository. Then CodeXL told me that my processor is not supported, and I went to sleep with this knowledge. Next day I found out that I still have to run the initialization script, even after installing it - and then ran into the problems mentioned at the beginning of this letter, namely that CodeXL might work, but OpenCL obviously doesn't, despite of the Catalyst drivers and all the mess.


So, my goal - to start doing GPGPU programming for my Radeon graphics card and 8-core AMD processor. But as it's not just my own fun, it also has to work on Intel computers, iPhones, Androids etc. - my final result. And this normally, if the library maker is not AMD, gives me quite a clear understanding of what I excpect from the libraries and tools (this time I'm cocksure about doing it with AMD, and I already knew that it's going to be problematic, but I list those things FYI):

- The programming environment samples must run *perfectly*, and compile to all supported platforms; in the current case they should work also on Intel systems, because AMD toolchain is advertised to be able to compile portable. So the AMDTeapot should work on AMD and Intel machines, at least in compability mode or software rendering, but basically - it should show that the libraries are portable. But - on the native platform, if this is the only supported one, the samples of a language have to work *perfectly*, and they also have to be able to perfectly make sure whether the platform is supported or not. This requirement might seem funny, but it's clearly not - the sample is meant to be simple exercise about the language/SDK features, and the SDK is supposed to be able to at least execute the programs; the writers of samples must be the people behind the SDK, who do it in the cleanest, most standard-compliant way, and show how it's right. So, if there is *any little trouble* with samples, unless it's really unrelated to this kind of questions (I would accept typo or the case if the sample keyboard controls are very bad, but not the case when the keyboard input is buggy itself), I usually have strong temptation to drop the whole toolset immediately - because if it's developers are unable to do the basic things of their framework in clean way, like starting up and setting up and executing and also resizing window or going into fullscreen and back, whatever they pretend to do there in this sample, then it's quite clear that the SDK is not built to even support these things properly, and if you want to use it, you should be able to do your testing on thousands of computers and situations; also, if those things won't work on current machines, you lack any guarantee of forward-compability of your code. So, enumerating standard devices, autochoosing one, etc. - if the SDK lacks any clean patterns for that, then we are going to be in trouble I really need a guarantee that when I compile, properly, the Windows, Linux, OS X and whatever other versions of my code, then unless I have a bug there, it will run and work. I can agree that there might be packaging challenges on more esoteric Linuxes or Linux versions, but that's all - if it turns out that I have to fix *one single bug* on SDK/library code to get it to run on target architecture, it will count like million little bugs in future - a clear red light.


That's it, basically. The samples and the example code have to do what they are supposed to do, on first compile and without any heavy hacking and searching. They should work on any OS.


So what I have now:

- Catalyst drivers work on Ubuntu. They don't work out-of-box as promised, but they work.

- CodeXL installer fails with "Power Profiler not supported on this processor family." (I have decent 8-core AMD processor, and Radeon graphics card, on supported motherboard), but I can unzip it and run the main executable.

- When I run the main executable and choose the AMDTeapot sample, it will run, but all the things available from OpenCL menu (like smoke and grid) are invisible, and I suspect that OpenCL does not work (because it shows very high framerate). I can choose my graphics card or processor from the menu, but this doesn't have any effect. When I maximize the window, OpenGL canvas does not resize, and when I normalize it again, it's hidden. Debug output is displayed about the OpenGL content - but I really did not go through all that to have an OpenGL debugger

- I have no idea, what to install or what to do, and I'm a little bit sick of searching. I mean, it's an official example and official tool from supposedly powerful and capable vendor.


Now as I have stated all that, I make a proposal to AMD, which I think would help you out from all this trouble:

Make your own Linux distro.


The distro would be:

  • Compiled from source, every package, to support only AMD CPU+GPU+supported chipset combinations, so that it doesn't install to any non-AMD platform.
  • Containing proprietary AMD tools, drivers and everything out-of-box.
  • Having nothing in the repositories, which won't work with the AMD drivers - all the stuff, which is not tested on the same platform, is blocked from the repos, and in case the version must be a little older than the most current, like the case with X Server, the newest version in repos is that older version. In case you have to turn off or on anything at compile-time to get it work, it's turned off or on, and in case some plugins, tools or modules would break the AMD compability, they are not available.
  • Developers are encouraged to do heavy optimizations on all levels of OS, which deliberately break support for any other platform, than AMD, in case this would give any advantage.
  • AMD is running automatized speed and compability tests on many AMD hardware settings - automated install of the OS, unit tests of all programs etc., with speed benchmarks. To make sure that things work out-of-box with AMD hardware, and utilize the capabilities.
  • Creators of other distros are free to take the optimizations and put them into ifdefs etc. on their platforms; anyway, as built-in inline call with processor optimizations is faster than generic call to hot-pluggable drivers, indeed the stuff would also run much faster on AMD hardware.
  • Minimal requirements would be OpenCL 2.0 support and decent processor, with maybe a branch with support of older hardware as well. This because with OpenCL 2.0 many things are changed and the OS should be targeting the future.
  • Sure, the tools and libraries should also support writing code for Intel platforms, and installation of game consoles and windows emulators should be acceptable and supported as well.
  • The programmers, implementers, etc., can be also members of open-source community, but the quality testing and unit testing must be supervised and controlled by AMD, and so the OS is not completely free - but it's completely useful. Because it would be one installer to install all AMD development tools and be sure that they will work without any additional mess. I mean - you have to already have set up many of these configurations, so in the first place you could "just" throw your selections into a repository and call it a new Linux, optimizations can come after?


So just give it to me With KDE and Gnome and XFCE desktops, because I love them all