cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

martinn1
Adept I

Adding dedicated GPU to Trinity based Linux system

Hi

I'm currently using a Trinity system running Linux that has worked well enough so far, but I believe I'm approaching the limits of the integrated GPU. I'm considering to add a dedicated GPU from the HD 7000 series and my question is how that will effect my ability to use the integrated GPU for OpenCL processing. I've seen a few threads describing problems related to new devices hiding old devices when added. Does the fact that this will be an AMD-only system increase my changes of being able to use both GPU devices for OpenCL computations? I assume that none of this will hamper the usage of the CPU device.

Will I be able to move all my monitors to the dedicated GPU, or will one of them have to be connected to the integrated GPU for it to be available to OpenCL? If so, will I be able to span my Ubuntu/KDE desktop seamlessly across monitors attached to the separate GPUs?

0 Likes
7 Replies
dmeiser
Elite

I've been running a similar setup for a while: integrated AMD GPU + 7970 + 6790. I can use all 5 devices (1CPU + 4 GPUs; the 6790 is a dual chip GPU) without problems using the AMD APP SDK (currently version 2.8, but earlier versions worked too for me) and AMD drivers (currently 13.1, but earlier versions worked too).

It's key that you get your bios settings right (keep the integrated GPU enabled) and you need to add all devices to your xorg.conf. I don't need to have GPUs attached to a monitor in order to use them. Currently I'm using two monitors on the integrated GPU but I'm not spanning the screens (i.e. xinerama is disabled). It shouldn't be a problem running all displays off the discrete GPU. I haven't tried xinerama in a while but if I remember correctly it was causing problems with OpenCL last time I tried (which was about a year ago). This may be fixed now.

Hope this helps.

Cheers,

Dominic

This is encouraging news indeed. I have managed to stay away from editing xorg.conf a great while (http://xkcd.com/963/) and have been doing all my configurations using the Catalyst Control Center (amdcccle). Is the CCC able to produce the required xorg.conf settings?

0 Likes

I think so. I use aticonfig (which is pretty much the same as the catalyst control center but for command line use) for producing xorg.conf files. I usually just run aticonfig --initial --adapters=all. That produces a pretty good starting point for xorg.conf. I suspect ccc can do the same.

0 Likes
himanshu_gautam
Grandmaster

Will I be able to move all my monitors to the dedicated GPU, or will one of them have to be connected to the integrated GPU for it to be available to OpenCL? If so, will I be able to span my Ubuntu/KDE desktop seamlessly across monitors attached to the separate GPUs?

Hi martin,

I was able to run a completely headless setup having AMD APU + discrete card. But I guess, if you are planning to have monitors on the system, display is likely to go to iGPU. iGPU has to be selected as primary video adapter in BIOS, in order to make this config work. But then I guess that is good, because your heavy GPU is totally free for the computation work, and need not driver the display. Probably you can try creating this setup, and let us know if you face in bumps.

A quick link to help you: http://devgurus.amd.com/message/1286878#1286878

martinn1
Adept I

So, I decided to get myself a 7950 and see what happens. I've managed to configure a setup that I'm happy with and figured that I should share my experience here for anyone who would try something similar. It wasn't quite plug and play. My starting setup was a Trinity A10 5800k system running Kubuntu 12.10 using the proprietary graphics drivers suggested by the "Additional Drivers" utility. Labeled as "ATI Fire GL" within the utility, these drivers are commonly referred to as "fglrx" by the Linux community. Attached to the system are three monitors, one of which is rotated into portrait mode.

To avoid any confusion, the following were my goals for the upgraded system:

1) A usable desktop.

This being Linux we're talking about, it's important to state the obvious. By "usable desktop" I mean that I should be able to open, view, and use applications on all monitors; widgets, panels, icons, and shortcuts I have on the desktop should all be visible and functional; and the desktop should be relatively stable in the sense that it should not crash or send me back to the login screen too often. Also, the portrait mode monitor should display it's part of the desktop with the proper orientation.

 

2) All OpenCL devices should be available.

With the inclusion of the 7950 I have three OpenCL devices in the system: the CPU part of the Trinity APU, the GPU part of the same, and the new 7950. Let's call these "Piledriver", "Devastator", and "7950", respectively. I want to have the ability to run OpenCL kernels on any and all of these devices. However, the "all" part is a bit relaxed in the sense that I don't need application to use both Devastator and the 7950 at the same time; Piledriver and either one of the GPUs is good enough.

3) I should be able to play games through the 7950 on my main monitor.

As some you may know, Valve released Steam for Linux not too long ago and it would be a shame to let all the shader cores of the 7950 miss out. I was pleasantly surprised in finding that some of the games I already had on Steam were available for Linux and only a short download away.

    

What follows is a summary of the various ways I tried, and failed, to find a configuration that fulfilled the three goals above. My current setup, which does fulfill the goals, is described under "Current setup" later in this post.

My first approach was to attach all three monitors to the 7950 in hope that I would be able to run Devastator headless. This turned out to be impossible. With no monitors attached to Devastator, KDE would hang on startup. This happened regardless of how I made the configurations in BIOS.

The second approach was to attach one of the monitors to Devastator and the rest to the 7950. This would hang as well until I changed BIOS to favor Devastator. This let me boot the system properly, but it would violate Goal 1 in all kinds of ways. Each reboot was like the spin of a tombola. The mouse pointer would wrap between monitors in unexpected ways, sometimes from one side of a monitor to the other side of the same monitor making the other monitors unaccessible. Dual, sometimes triple, X screens were created. My wallpapers, panels, and widgets would move seemingly random between my monitors, sometimes confined to only one of them, sometimes spanning two. Maximizing windows would sometimes make them span two monitors which due to the difference in vertical resolution would make the title- and menu bars invisible. At no point in time was I given a configuration where I could reliably and predictably move the mouse pointer between the three monitors, and sometimes I would not get a desktop at all on some of the monitors, just the KDE logo.

I understand that, apparently, using more than one GPU necessitates the use of more than one X screen, one per GPU, but even with this knowledge I was unable to configure my setup properly. I spent quite a bit of time with this approach, trying various ways to connect my three monitors to the two GPUs and configured them using various variations of aticonfig and amdcccle, with spurious "sudo rm /etc/X11/xorg.conf" thrown in for good measure. I have found that the two tools tend to mix up each other's entries in xorg.conf and I found it safest to clear it completely and letting each tool generate it from scratch. Didn't help much though. Having more the one X screen always broke something, violating Goal 1.

Current setup

 

Having given up on multiple X screens, the next step down the abstraction ladder is to have multiple X servers. This, at least according to my reasoning, would hide the existence of the other GPU from each X server and thus prevent the agony I suffered while abearing dual X screens. This approach prevents an application running on the X server for one GPU from using the GPU dedicated to the other GPU. While unfortunate, this is the best I've managed to achieve so far and the reason for the wiggle room given in the description of Goal 2.

The monitor-to-GPU connection is that all monitors are connected to Devastator, which is the primary GPU. BIOS is displayed through Devastator and the primary xorg.conf used by the default window manager contains this GPU and all three monitors. The trick is that the main monitor has a second signal cable attached to the 7950. A second xorg.conf, cleverly named xorg.conf.single, lists the 7950 and the single monitor attached to it. Whenever I wish to use the 7950, either for OpenCL or gaming, I open up a terminal and run

 

  $ startx /usr/bin/startfluxbox -- :1 -xf86config ./xorg.conf.single

 

This command will start a new X server on tty8 and switch to that. All monitors goes to sleep and I have to switch input on my primary monitor in order to see my gluxbox desktop. This setup presents a single-monitor desktop to the games, which I'm sure will save me some grief in the future. Also, my main work environment is now exactly like how it was before I installed the 7950. A familiar desktop indeed.

Not quite optimal, but it works well enough for my needs.

    

One question I still have concerns driver versions. The discussion himanshu.gautam linked to contains many references to driver versions such as 12.10 and 13.1. These appears to be dates, following the year.month format. How do I find the version of my currently installed driver? Using amdcccle I found the following version string.

 

  9.00.11-120920a-147436C-ATI

 

Within the string I find the date 120920. To convert this date into a driver version, should I truncate the day part, giving 12.9, do a proper rounding, up to 12.10 in this case but future dates could contain a lower day number, or always round up to 12.10?

Thanks for the detailed write up. I've got this thread bookmarked.

Dominic

0 Likes

One question I still have concerns driver versions. The discussion himanshu.gautam linked to contains many references to driver versions such as 12.10 and 13.1. These appears to be dates, following the year.month format. How do I find the version of my currently installed driver? Using amdcccle I found the following version string.

 

  9.00.11-120920a-147436C-ATI

 

Within the string I find the date 120920. To convert this date into a driver version, should I truncate the day part, giving 12.9, do a proper rounding, up to 12.10 in this case but future dates could contain a lower day number, or always round up to 12.10?

Thanks for sharing your experience in detail. It will help a lot of other people

For the Driver version question you are right about 12.10 and 13.1 as being the dates of their release. Although I am also not sure to what version "9.00.11-120920a-147436C-ATI" map to. Probably someone else can help there. Anyways it is recommended to use the latest drivers which can be downloaded from AMD website directly.

0 Likes