7 Replies Latest reply on Mar 19, 2015 2:07 PM by qtvali

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

    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

        • Re: About my initial experience about CodeXL, and some ideas about AMD
          dorono

          Hi qtvali,

          Thanks for this detailed report. There are a lot of issues to address here. I'll work on the CodeXL part. I'll also make the Catalyst Installer team aware of this post. The AMD distro idea is cool! I'll kick it upstairs and see if anyone catches the ball

          Can you please share a few details:

          • What Catalyst release are you using?
          • What model AMD HW are you using?
          • Can you upload the CodeXL log files? They should be stored under /tmp/ Look for 2 files: CodeXL-your_login_name.log and CodeXLServers-your_login_name.log
          • Did you install the AMD APP SDK? Can you try to debug one of the SDK OpenCL samples, such as BoxFilterGL and see if it works?

          I agree with your view that the toolset + sample application should work perfectly out of the box.

          CodeXL supports Red-Hat and Ubuntu distros, Gnome and KDE desktops. XFCE is not a supported desktop. CodeXL may or may not work on it - we simply don't test it so I honestly don't know.

          1 of 1 people found this helpful
            • Re: Re: About my initial experience about CodeXL, and some ideas about AMD
              qtvali

              My system configuration as returned from "inxi -Fx" (I hope it's helpful):

              Pasteboard — Uploaded Image

              (I have nothing to do with the toolset with the same name as my host:D)

               

              Motherboard: 990FX Extreme3

              CPU: AMD FX-8350 Eight-Core (-MCP-)

              GPU: Advanced Micro Devices [AMD/ATI] Tahiti XT HDMI Audio [Radeon HD 7970 Series]

               

              Right now the error message is not available, because I installed fglrx-14.501.1003 by generating Ubuntu drivers, and now it doesn't work at all:

               

              From App output file:

              Debug string: CodeXL's OpenGL Server initialization has failed. The debugged application will now exit

               

              Tomorrow I will fallback to older driver again to test - right now it's 12:53 at night here

               

              I havent APP SDK (I tested it before on nVidia machine, with Linux and Windows, where it worked), but I did download one separate example for OpenCL, and with both Ubuntu-repository and current versions it tells - "SVMBinaryTreeSearch":

              Platform 0 : Advanced Micro Devices, Inc.

              Platform found : Advanced Micro Devices, Inc.

              Selected Platform Vendor : Advanced Micro Devices, Inc.

              Device 0 : Tahiti Device ID is 0x128fcb0

              Expected Error: Unsupported device! Required CL_DEVICE_OPENCL_C_VERSION 2.0 or higher

              • Re: About my initial experience about CodeXL, and some ideas about AMD
                qtvali

                So, now I started to question my hardware.

                Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X]

                 

                AMD OpenCL™ 2.0 Driver - this list says that R9 200 series is supported; naturally I would suppose that 280X is 200 series, but at the same time 7970 or 8970 don't exist in this list.

                AMD Radeon Rx 200 Series - Wikipedia, the free encyclopedia - this Wikipedia article says that R9 280X has OpenCL 2.0 support.


                So from another AMD person, I now find out that OpenCL 2.0 is not supported for 280X, and not planned to support, which would explain everything very well:

                Re: Can't get any opencl 2.0 samples run from the latest 3.0 SDK. - this question, at the same time, is closed telling that my card is not supported; it links to http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/system-requirements-driv…, which lists R7 200 series, but not R9 200 series (only R9 290 and 290X). List of platforms supported by OpenCL 2.0 driver - here it confirms.

                AMD Radeon R9 280x performance in CompuBench - performance benchmark for various compute APIs (OpenCL, RenderScript) - here it also gives OpenCL 1.2 as opencl_c_version.


                Which might mean that both Wikipedia article and OpenCL driver page are misinforming? Anyway, the driver page explicitly lists M280X, which is the mobile version of the same model?


                Which actually means that 280X cannot access the main memory of the computer?


                Graphics Core Next - Wikipedia, the free encyclopedia - here, it says GCN 1.0 supports unified virtual memory, which is actually what I'm most interested in.


                Anyway, then I'm overly confused, because all the sources seem to confirm that my card has shared memory support, which, then, is also the main feature of OpenCL 2.0? Can I utilize it with OpenCL 1.2, or how should I think about this? And how can I then assure that my applications are compatible, if it has it's own hacks for this, and which OpenCL 2.0 specifics my card won't support?


                Can I still run the examples with this compiler - pocl - Portable Computing Language? Because as I understand, I don't have so many generic algorithms available for v. 1.2, and they won't last the time-test if I start writing them myself?

                 

                My current actual goal would actually be to implement a language of my own, which would allow to simplify some things we are doing here, about graphics and augmented reality - about 50% of it would be syntactic sugar for things like OpenCV, and the other 50% would take care that things, which happen between two OpenCV calls etc., won't be the speed bottleneck. Right now I just want to implement a very limited source-to-source compiler, which ultimately generates bindings to another language. As I like programming languages theory, I have more ambitious plans for it, but at the moment I just need a small useful tool to do the job. As our company is doing 3D and AR apps for phones, also stuff like 3D reconstruction in the future, I want to make sure that what I do is able to use AMD shared virtual memory, at least, and I thought it's the cheapest video card to test that Now we are like 7 people working here every day, three of us practicants of universities. So basically what I need is to play videos from my hard drive and run all kinds of algorithms on those videos, and to make sure that the scripts calling those algorithms also utilize as many cores as they can. So with my goal, it hasn't definitely to be OpenCL 2.0 - it simply has to be something, what can utilize the memory bridge on my computer, as the other devices are mostly iPhones and Androids, which I have to target as well, and which run older versions of OpenCL. As things I run on my computer are more or less "just for myself", I decided to be very AMD-specific, especially after the UEFI on Intel machine started to tell me that my Linux installers are not proper Windows installation media, and other such kind of stuff, which somewhat fears me Maybe an irrational reason, but I'm not going to trust, what Intel and Microsoft are going to do together, and I fear that they want to turn my computer into a toy. And apart from this personal sympathy, I just found that the shared memory architecture *is* a future technology, and underneath the AMD cards must be much better than nVidia's cards, in case we figure out, how to do something useful with them So much about my background, which should tell you, what kind of information I need - nobody has told me that I need to use OpenCL 2.0, but I definitely need to use this shared memory, and I definitely need a bunch of algorithms to be available, like sorting, reducing and some other, which I want to have as first-level citizens in the syntax. So, writing a debugger is one of the advanced tasks we obviously cannot achieve ourselves with this team here, and then CodeXL would be just the tool we need. In case it really supports my processor and video card, finally Otherwise we start debugging next year, when I buy some more advanced video cards

                 

                So in case you didn't want to read the whole story, I have a question to get a definite answer - is CodeXL supposed to work on my computer with any version of OpenCL, and with whatever language or (other) tool I need to utilize the shared memory?

                 

                Thank you!

                • Re: About my initial experience about CodeXL, and some ideas about AMD
                  qtvali

                  I replied in the Forum more clearly about what I want to do, also that I

                  started to suspect that the information about my video card might be wrong

                  - Wikipedia says that my card is OpenCL 2.0, and Catalyst page says that it

                  belongs to a series, which is OpenCL 2.0, but maybe it's the one, which is

                  not. There I also explain, what I want to do. I can send you any feedback

                  about the card and my experience, but now my question is rather what

                  exactly I can do with this card, not only how I'm not going to buy a new

                  one at the moment.

                   

                  But currently, what I really want to do, is a little test for GPGPU in

                  general, or more like a test for OpenCL. In the past I have had interest

                  for parallel programming, but last 2 years I have been away from computing,

                  and some things have been changed - including the fact that things I used

                  to dream about are turning common reality.

                   

                  All other things, I better discuss in public, but to show you what I need

                  to do right now, I send the pdf file of another letter, where is a result

                  of one my Python test - I prototyped in Python, what I want to turn into

                  OpenCL or other GPU-parallel program now.

                   

                  What I need to, comes from the fact that 3D reconstruction software for

                  mobiles usually needs you to move the camera around, to get any depth

                  information; if you keep your camera still, it won't collect anything. I

                  figured out that the mobile cameras do indeed focus images, and focusing

                  should be like 3D-scan, where the sharp blue line goes into depth and back.

                  It's hard to control the focus of those phones, but autofocus more or less

                  moves very fast from one extreme to other to back, and gathers multiple

                  intermediate frames meanwhile. So I need:

                   

                     - To gather the frames from the mobile camera, or computer camera,

                     together with focus information, if available. On Android, the only way to

                     call autofocus extreme-to-extreme function is choosing some random area for

                     focusing, but when it works, it feeds you some information about the

                     current focus through callbacks. The frames I gather with OpenCV library,

                     probably, which works on Android, iPhone and desktops as well.

                     - To run an algorithm on every frame, which should give similar results

                     to what I send with this letter. For the results of the pictures, it's not

                     easy to discriminate, whether the effects come from light, focus or

                     sharpness of the area, because the algorithm does not exactly discriminate

                     between these; but I can see from there, that it still very sharply

                     understands, that unfocused area is not focused.

                     - To try to create a virtual Kinect driver, which emulates a Kinect

                     device with all it's problems - sometimes giving the depth information,

                     sometimes not, and well ..there should be some application-specific hacks,

                     like one application needs rather reliable frames only, whereas the other

                     application needs any data, which is available. So the driver should figure

                     out, which application is using it, and configure itself appropriately.

                   

                  Kinect devices, as you might know, are very-very unreliable and give very

                  low-quality information as they draw infrared pattern on surroundings, and

                  then depend on the reflections of this pattern, so this technology is far

                  from being clean true 3D camera - for example this Kinect shot has nothing

                  to do with reality: https://www.youtube.com/watch?v=1Qx8NzuSSJ4. So the

                  applications should be aware that it's low-quality information, which can

                  often be straight wrong; so what I will do doesn't have to be perfect - but

                  it would enable some applications, which now run only with special

                  hardware, to be run on normal mobile phones. Especially, of course, if the

                  phone has wide lens But now, if I can take an open source camera, make

                  it do the focusing cycle every time it stops, and utilize the script to

                  give the user some hints about how to use the camera and how to move - then

                  I would really need much less different angles and movements to do the

                  whole 3D reconstruction, and probably I can feed my preprocessed input to

                  some other programs, which take the depth hints and then utilize those in

                  some more advanced logic. For this, I would use currently my computer, and

                  try to maximize the use of it's capabilities - 8-core processor and 2000

                  processing units should not be bad, right? - to run more logic, to create

                  more authentic depthmap, and then to feed it to some program, which needs

                  Kinect device.

                   

                  The examples in the letter use quite trivial algorithm - they take two

                  pixels in every direction, measure the smoothness of those two pixels and

                  then make the output pixel as much darker as more blurred the area is. It

                  clearly understands depth well from the identical flowers, so that the

                  flowers on the foreground are detected as being foreground - the sky,

                  anyway, has a kind of defocus this algorithm does not easily understand.

                   

                  https://www.apertus.org/es/en - there is also this open source camera,

                  which can be connected to computer and reprogrammed; this setting is

                  different from the mobile, and should utilize more of the GPU power to run

                  more advanced logic on more pixels - for example, to cover also the blank

                  areas with depth information etc., and to analyze the camera movement a

                  little bit. I want to keep it a low-level algorithm, which does not do any

                  advanced processing about the image content or actual geometry, to not

                  duplicate the work later done by client program - I just need to take so

                  much hints that I can make sure that the depth information is no-nonsense,

                  and that the client program can suppose that it's more or less realistic

                  depthmap; as it's a driver meant to emulate hardware, it must not take more

                  than a few percents of processing power itself, because the client program

                  supposes that it got all. Client programs are programmed to use it only as

                  hints - it's rather needed to keep track of objects, than to determine the

                  3D pointcloud itself, because also the Kinect device I'm going to emulate

                  gives often quite random and estimated data, or sometimes no data at all.

                  So I believe that if I make the - very slow - Python program used to test

                  the conception into nice parallel realtime app, I have achieved something.

                   

                  So if I can do this, either in OpenCL 1.2 or OpenCL 2.0, and test it with

                  CodeXL, it would be a nice start. We also have a corporate partner, who

                  would be somewhat impressed by this technology, and who is supporting us.

                   

                  Tambet

                  • Re: About my initial experience about CodeXL, and some ideas about AMD
                    qtvali

                    Also, the other thing ..I'm (hopefully) going to build a programming

                    language on top of these technologies now at my hand. Sorry for these

                    things not being much in topic, but I just want to show my intent - so if

                    you don't have much time, you don't even need to read this message But I

                    will be happy if I can share my experience and get some support from AMD,

                    because this would turn my project much more serious, much faster, and what

                    I describe here, maybe it's possible to utilize some optimizations of

                    technologies you are well aware of.

                     

                    One thing I want to do is to implement fully a projection I made when I was

                    a child, and which is now used by some people as "Lollipop" without any

                    explanations and without reference to me ..I don't know if they reinvented

                    or used my version, but it's like invented by nobody now Anyway, I wrote

                    about this and so at least nobody can patent it. They don't, anyway, use

                    the advanced properties of this projection - to project a square texture

                    onto a sphere without distortions. There are actually some distortions in a

                    sense, but not the kind of distortions, which produce the flickering of

                    north and south poles in Google Earth - rather a kind of very useful

                    distortions.

                     

                    It's basically utilizing the fact that triangles drawn on sphere have the

                    exact same properties as triangles on pixel texture (it's very important

                    that it's a pixel texture and not a paper, because on paper you have the

                    same amount of information in same-length line to any direction, but in

                    computer you have squared pixel "points").

                     

                    If you draw 4 triangles on the north pole, you can turn it into a square

                    like this:

                      • Re: About my initial experience about CodeXL, and some ideas about AMD
                        suma

                        Hi qtvali,

                        You mentioned in your response that, "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”


                        We would like to understand the Install issues you went through.

                        "I had installed Ubuntu with Gnome, failed with it", according to you "failed" means what? Does X hangs or system hangs?

                        Did you try to install on fresh machine ? If not, did you try to purge remove the previous packages (on Ubuntu)?

                        Can you send the "atigetsysteminfo.sh' script output file? It will help us to understand your system better.


                        Please help us to reproduce the issue in house.

                          • Re: About my initial experience about CodeXL, and some ideas about AMD
                            qtvali

                            Yes it's a little bit of problem now, because I left this company - it

                            turned out that they don't want to offer me a part of the company, as they

                            initially kind of said, and soon we broke up

                             

                            "Failed" means that on Gnome 3 (and from forums, this 3 is important) on

                            both machines I got basically just a screen which said "something went

                            wrong", on login - I dont remember the exact wording now. Yes, all installs

                            were fresh

                             

                            I will try to write longer next time!

                             

                            Tambet

                             

                            On 16 March 2015 at 14:02, Sumalata Hiremath <developer.forums@amd.com>