cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

martinn1
Adept I

Trinity GPU and discrete graphics cards.

I'm reading reviews of the desktop Trinity APUs and found the following bit on XbitLabs:

Besides, AMD hasn’t yet come up with a solution that would allow using the GPU resources if there is a discrete graphics card installed into the system 

http://www.xbitlabs.com/articles/cpu/display/amd-a10-5800k_11.html

Is this true?

0 Likes
14 Replies
binying
Challenger

Shouldn't openCL be counted as sth. if it is not a "solution" yet?

0 Likes
yurtesen
Miniboss

If I had a powerful GPU, I think it would still pay to use it for tasks instead of whatever packed in an APU... But there is no reason for applications such as winzip etc. to not able to utilize GPUs in APUs for accelerating using OpenCL even when there is a 2nd OpenCL capable device is available. Although currently I dont have access to such system there was a recent post from somebody who had a trinity APU with an additional GPU...

http://devgurus.amd.com/thread/159698

Can you ask xbitlabs what they mean exactly in their article?

0 Likes

I believe what they mean is that in Linux the default driver settings don't make it easy to use both APU and discrete GPU at the same time. I'm currently reinstalling Linux, but the last time I tried I also had the same problem. My programs could only find one of the GPUs to use depending on the settings in the catalyst control panel(high performance vs low performance). While in windows I didn't have to mess with any settings, my programs could find both the APU and discrete GPU without any problems after updating the drivers.

0 Likes

So this means that it isn't a limitation in hardware but something that we can expect to be fixed eventually. Will you let us know how things turned out once you're done reinstalling Linux?

0 Likes

I have a Llano APU with a discrete card. After installing Linux I had no configuration problems as before. Before I had to manually configure the settings for display adapters or something like that for the X server. That was ubuntu 11.x.

If I have time I could try Fedora, and OpenSUSE too.

Procedure:

Installed Ubuntu 12.04. Installed all updates.

Installed APP SDK and checked if the programs worked on the CPU only.

Then downloaded 12.8 drivers, made the Ubuntu/precise packages. Installed those using dpkg.

Ran aticonfig --initial.

OpenCL programs could use the Llano Cpu, Llano GPU, and discrete GPU without any problems. Didn't do any thorough testing though.

My guess is something wasn't setup right with their computer.

Update: err, maybe I spoke too soon.  Today it will only let me use the discrete card and cpu. I don't have time to mess with it these days. This time I installed the AMD APP after the drivers(which is what's recommended in the install notes). Maybe I was just confusing the CPU with the CPU's GPU earlier... I'll check again when I have time.

0 Likes

This is pretty much the situation I'm afraid of ending up in as well. One has to give up quite a bit of CPU performance when going for a Trinity instead of one of the 8 core CPU-only processors and I'm reluctant to do that when the IGP is as unreliable as it seems to be at the moment.

I'll wait a while and see if more positive reports emerge as drivers mature or whatever the current problem might be.

0 Likes

I dont quite understand what is to be afraid of? There are not many (if any) general purpose applications which take advantage of OpenCL on Linux yet. Therefore I would say that you wouldnt see any difference in performance if you had discrete graphics or not when using trinity apu from the pure processing power point of view under Linux. Also, the drivers probably work fine when configured properly. (and gpu within apu works fine with no configuration on Windows so...)

AMDs OpenCL drivers require GPU to be actively defined in X configuration, that is the only problem with the drivers. People have been complaining about this for years now. I dont think AMD will change the drivers anytime soon. It would have been awesome if the GPUs could run OpenCL code even when not connected to an X display.

0 Likes

yurtesen wrote:

I dont quite understand what is to be afraid of? There are not many (if any) general purpose applications which take advantage of OpenCL on Linux yet.

Being a software developer, I feel that it is my responsibility to change this. It is my understanding that the intended usage of the available hardware in a heterogeneous machine is to run some parts of the program on the host when that makes sense, use the IGP when that makes sense and to move data to a discrete GPU whenever that makes sense. We have had a few years to experiment and make ourselves familiar with the host+GPU part, but IGPs that are useful didn't really exist until Trinity. I'm really looking forward to writing an application that scales well as all three device types improve with new generations.

yurtesen wrote:

Therefore I would say that you wouldnt see any difference in performance if you had discrete graphics or not when using trinity apu from the pure processing power point of view under Linux. Also, the drivers probably work fine when configured properly. (and gpu within apu works fine with no configuration on Windows so...)

AMDs OpenCL drivers require GPU to be actively defined in X configuration, that is the only problem with the drivers. People have been complaining about this for years now. I dont think AMD will change the drivers anytime soon. It would have been awesome if the GPUs could run OpenCL code even when not connected to an X display.

I'm a software developer, not a system administrator or driver configurer. Sure, I can install a new graphics driver and have messed around in X configuration files before, but that is not something I want to spend multiple hours on. It is one of the things that should just work. When I see thread like this http://devgurus.amd.com/message/1283726 I can't help but get a little nervous.

0 Likes

Martin Nilsson wrote:

Being a software developer, I feel that it is my responsibility to change this. It is my understanding that the intended usage of the available hardware in a heterogeneous machine is to run some parts of the program on the host when that makes sense, use the IGP when that makes sense and to move data to a discrete GPU whenever that makes sense. We have had a few years to experiment and make ourselves familiar with the host+GPU part, but IGPs that are useful didn't really exist until Trinity. I'm really looking forward to writing an application that scales well as all three device types improve with new generations.

I still think you would be better off using the discrete GPU in nearly all cases even if you have access to both IGP and GPU. Therefore this is not a really a huge problem. But I agree that there is a problem, but the problem is not due to a bug, it is by design... I tried to explain it below... (after the rant about Linux )

I'm a software developer, not a system administrator or driver configurer. Sure, I can install a new graphics driver and have messed around in X configuration files before, but that is not something I want to spend multiple hours on. It is one of the things that should just work. When I see thread like this http://devgurus.amd.com/message/1283726 I can't help but get a little nervous.

If there is anything certain about using Linux, you need to spend hours to configure stuff Often neither Nvidia nor AMD drivers install properly at all after there is an upgrade to kernel even. These problems are not only because of AMD, but also due to how unorganized Linux developers are.

About the problem in AMDs drivers, If you check the 'settle''s message in the thread you have mentioned, he was saying exactly the same thing. You need to configure X to use both GPUs to be able to access it using OpenCL. I agree that there shouldnt be need to attach the GPU to X server to utilize it for OpenCL, however if you check the forums, you would see that people were complaining about this for several years already, without any definite response from AMD...

I think AMD is simply not interested in their devices being used for computation on Linux. What do you suggest we do to convince them? March to their office? If there was a possibility to add a poll for this feature, I would have posted it already hehe

0 Likes

yurtesen wrote:

I still think you would be better off using the discrete GPU in nearly all cases even if you have access to >both IGP and GPU. Therefore this is not a really a huge problem.

Absolutely not. I'm confident that there are cases where it doesn't pay off to move a bunch of data over to the GPU and then back again. It may be due to insufficient number of work items to use the larger hardware efficiently, or not enough consecutively parallel sections of work to make up for the transfer cost back and forth. What I envision is an application that is largely serial, or possible task parallel with serial tasks, but with data parallel sections sprinkled all over the execution timeline. In such a case it may be hard to find parts which are desirable to move over to the GPU, but if we have a massively parallel floating point number cruncher with access to main memory then it's a no-brainer. Whenever a data parallel section comes up then pass it on the to IGP and with very low overhead let it burn through the work item. And if possible keep the CPU occupied with other stuff in the meantime. This is the usecase I want to experiment with. Can a weaker CPU with the help from a IGP outperform a stronger CPU with more cores but no IGP in the workloads I'm interested in? We have already tried the GPU approach and found that we can indeed get a significant speed-up this way, but only with workloads that are a lot larger than what we typically use our software for. It's great for demos and boasting, but not really useful in our day-to-day work.

yurtesen wrote:

If there is anything certain about using Linux, you need to spend hours to configure stuff. Often neither Nvidia nor AMD drivers install properly at all after there is an upgrade to kernel even. These problems are not only because of AMD, but also due to how unorganized Linux developers are.

This certainly was the case a few years ago, but I have seen tremendous progress since then. Nowadays it is in many cases possible to setup and use a Linux machine without any problems at all. It is mainly the bleeding edge stuff, in which I include what we're talking about here, that presents difficulties. For how long will a IGP be considered bleeding edge?

yurtesen wrote:

About the problem in AMDs drivers, If you check the 'settle''s message in the thread you have mentioned, he was saying exactly the same thing. You need to configure X to use both GPUs to be able to access it using OpenCL. I agree that there shouldnt be need to attach the GPU to X server to utilize it for OpenCL, however if you check the forums, you would see that people were complaining about this for several years already, without any definite response from AMD...

The end of settle's response reads "If you get this to work how I think you want it to work (both fully functional independent of the other), please let me know how.", which indicates that something isn't quite right. Also, how to properly configure X does not seem to be something that is properly described in the installation instructions since the question keeps showing up. The latest incarnation I found is in this thread http://devgurus.amd.com/message/1284358.

From what I understand, I would have to attach a monitor each to the IGP and the discrete GPU and make sure that my desktop is visible on both of them in order to use them both through OpenCL. How will this be handled if the discrete GPU is from another brand? How will OpenGL applications behave? Last time I had OpenCL drivers from two vendors installed at the same time AMD's platform became inaccessible and would crash the application whenever I called clCreateContext. This is exactly the kind of problems I think about when you talk about "how unorganized Linux developers are.".

Unfortunately, I don't have access to a APU at the moment so I can't try it out for myself and see how hard it really is and what kinds of compromises that are required in order to make it work. If I'm to spend a bunch of money on this then I need to know that I'll get for it. Otherwise I'll rather wait.

yurtesen wrote:

I think AMD is simply not interested in their devices being used for computation on Linux. What do you suggest we do to convince them? March to their office? If there was a possibility to add a poll for this feature, I would have posted it already hehe

I think we should do exactly what we are doing right now. Discuss problems, workarounds, and solutions in their official forums. This way we can spread knowledge and discoveries not only among ourselves but also help the developers at AMD and others become aware of the flaws and inconsistencies in their produces and hopefully motivate them to fix the problems. They need to be aware that there is a community out here that is dependent on their products and that tries to be as helpful to them as it can. Even the Linux users.

0 Likes

Absolutely not. I'm confident that there are cases where it doesn't pay off to move a bunch of data over to the GPU and then back again. It may be due to insufficient number of work items to use the larger hardware efficiently, or not enough consecutively parallel sections of work to make up for the transfer cost back and forth.

If the task is small enough, it would probably make more sense to use threads on the CPU. If the tasks is heavy, then it would probably be ok to send to discrete GPU even with data transfer overheads. APU is definitely the way to go if you dont have a discrete GPU, but things are not so black and white if you have a discrete device assisting. You will be stuck with a very small set of possible scenarios where using APUs GPU might benefit you

Of course it is probably useful to offload calculations to GPU if you are running heavily threaded programs and another thread can take advantage of the idle core. But it probably will be difficult to get a single program to offload some calculations to GPU while doing something else in CPU since often that single

program will need the results to continue processing.

For how long will a IGP be considered bleeding edge?

It depends on you I guess Just few months back Nvidia drivers did not install on Fedora. Do you think Nvidia GPUs are overall considered bleeding edge then? Have you tried to make a google search of 'nvidia driver kernel problem' ? I get all sorts of results starting from kernel panics to drivers not installing etc.

What you are saying about Linux is definitely not true. We routinely have problems with Linux after normal updates. One day Intel RAID 1 would stop working and break the array after an update, sometimes after standart reboots... since when RAID1 is the bleeding edge?  next day ethernet would stop after a kernel update (and yes, it happened with off the shelf realtek gigabit ethernet card just last week that I had to install realtek drivers manually) and gigabit ethernet while is not so common, shouldnt be bleeding edge!, in my laptop my broadcom wireless/bluetooth card which also acts up and I can go on....

If you think that this is stable for Linux, then you should clearly accept that you need to configure a graphics card in X windows for getting OpenCL programs to run on it eh?

The end of settle's response reads "If you get this to work how I think you want it to work (both fully functional independent of the other), please let me know how.", which indicates that something isn't quite right. Also, how to properly configure X does not seem to be something that is properly described in the installation instructions since the question keeps showing up. The latest incarnation I found is in this thread http://devgurus.amd.com/message/1284358.

From what I understand, I would have to attach a monitor each to the IGP and the discrete GPU and make sure that my desktop is visible on both of them in order to use them both through OpenCL. How will this be handled if the discrete GPU is from another brand? How will OpenGL applications behave? Last time I had OpenCL drivers from two vendors installed at the same time AMD's platform became inaccessible and would crash the application whenever I called clCreateContext. This is exactly the kind of problems I think about when you talk about "how unorganized Linux developers are.".

Unfortunately, I don't have access to a APU at the moment so I can't try it out for myself and see how hard it really is and what kinds of compromises that are required in order to make it work. If I'm to spend a bunch of money on this then I need to know that I'll get for it. Otherwise I'll rather wait.

I never disagreed with the conclusion that the way things work now is sort of inconvenient and things can be improved. You shouldnt have to attach a monitor, you only have to set the devices to have a display in X configuration.

I believe you will have problems if your discrete GPU is from another brand, this does not work well even when 2 discrete GPUs from 2 different brands sit in a normal desktop machine. If you have a discrete GPU, you still should use AMD's GPU in the X configuration, therefore you cant use the 3rd party GPU for video output.

I tried once to set both AMD and Nvidia on the same X server, and found out it was not good idea to try to load drivers from 2 vendors to X.

That said, this works all fine on Windows, so maybe the problem is not from AMD or Nvidia, and you might want to discuss it with X / Linux developers? But they will simply dismiss you I think

What I mean is that if there is a problem, the same problem applies to discrete devices, and also from different brands, and somehow only on Linux. So maybe it is just simply much more difficult to get this working in Linux from the driver developers point of view. I dont really know, but it would be premature/unprecedented to assume the problem is caused by AMDs drivers or devices.

I think we should do exactly what we are doing right now. Discuss problems, workarounds, and solutions in their official forums. This way we can spread knowledge and discoveries not only among ourselves but also help the developers at AMD and others become aware of the flaws and inconsistencies in their produces and hopefully motivate them to fix the problems. They need to be aware that there is a community out here that is dependent on their products and that tries to be as helpful to them as it can. Even the Linux users.

This has been discussed several times, for some reason they are not able to separate/free GPUs from X server. I am less worried about mixed GPU environments etc. but if they have to fix something, AMD should get GPUs to work independent of if X is up and running or not.  This is a fundamental problem for computing with AMD cards, After they fix that, they can start fixing other problems...

0 Likes

Fedora is bleeding edge distribution

main problem of AMD and nVidia driver in same Xserver is that they are overwriting same files from Xserver so you end up with broken X server. i am sure that you can run two Xservers on nVidia and AMD graphic card with opensource drivers just fine. AMD and nVidia need to use KMS so it can work.

there is hope for Xserver separation http://devgurus.amd.com/thread/159815

0 Likes

nou wrote:

Fedora is bleeding edge distribution

main problem of AMD and nVidia driver in same Xserver is that they are overwriting same files from Xserver so you end up with broken X server. i am sure that you can run two Xservers on nVidia and AMD graphic card with opensource drivers just fine. AMD and nVidia need to use KMS so it can work.

there is hope for Xserver separation http://devgurus.amd.com/thread/159815

Wow, thats amazing news.  So it should also fix the problem that Martin is worried about with the integrated and discrete GPUs.

Just as a side note, I thought nvidia overwrote libgl stuff, but amd did not? If you are using nvidia driver from elrepo, it installs the libraries to a different location and does not overwrite any X files. I am not sure how this works on Ubuntu...

eg. http://pkgs.org/centos-6-rhel-6/elrepo-x86_64/nvidia-x11-drv-304.43-1.el6.elrepo.x86_64.rpm.html

0 Likes

The xbitlabs article in the first post was running benchmarks on windows only. Therefore the information that xbitlabs is giving seems incorrect (or not clear to us exactly what they mean). I perhaps should mention that people are even running APU+discrete crossfire setups...

I dont have such a system, but in Linux you have to set a display for each Radeon, even if there would be 2 discrete graphics cards. Otherwise you cant see one of them, and many people are having problems with that setup even. Therefore unless if there is a restriction of some sort which does not allow both GPUs to be used in xorg configuration in this manner in an apu+discete system, it should be possible to use them simultaneously for computing also.

0 Likes