cancel
Showing results for 
Search instead for 
Did you mean: 

OpenCL

Highlighted
Miniboss
Miniboss

Re: Trinity GPU and discrete graphics cards.

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 Kudos
Reply
Highlighted
Adept I
Adept I

Re: Trinity GPU and discrete graphics cards.

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 Kudos
Reply
Highlighted
Miniboss
Miniboss

Re: Trinity GPU and discrete graphics cards.

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 Kudos
Reply
Highlighted
Exemplar
Exemplar

Re: Trinity GPU and discrete graphics cards.

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 Kudos
Reply
Highlighted
Miniboss
Miniboss

Re: Trinity GPU and discrete graphics cards.

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 Kudos
Reply