This howto attempts to provide some information about running OpenGL (and OpenCL) applications on the ATI discrete graphics card on many of the recent notebooks that come with a Intel/ATI hybrid graphics system. It is primarily aimed at the recent notebooks with the PowerXpress 4.0+ model, which are "muxless", i.e., don't have a hardware switch to toggle between integrated and dedicated graphics -- there is no way to turn off the integrated graphics completely (in the bios or using a physical switch) and use it as a simple single graphics card system with just the discrete graphics card. For a more or less current overview of the state of hybrid graphics in general, see [1].

Since I could not find much information on the web about using the discrete graphics on these systems, I decided to try out a few things on my machine and this howto is a summary of the results. One can use either the proprietary ATI drivers (fglrx) or the opensource radeon drivers to get graphics acceleration. However, I prefer using fglrx, since it offers more features, including nice OpenGL performance (which is expected out of these upper mid-range GPUs) and support for running OpenCL applications. Also, it is neatly done - we get to use the Intel KMS (Kernel Mode Setting) with the Radeon doing the rendering! A word of caution is that I still prefer using the Intel graphics usually since the machine runs hot with fglrx (or radeon) and I feel a slight lag while using fglrx (possibly due to the graphics from radeon being routed through the intel graphics).

To use the opensource radeon drivers, currently the only working way seems to be along the lines of the Bumblebee and Ironhide projects (see [2] and [3]) for Intel/Nvidia hybrid graphics (also muxless, known as Optimus and is anologous to powerexpress) that start a second X server on the discrete graphics card and then use VirtualGL (see [4]) for running (rendering?) OpenGL applications on the second X server while outputting images to the primary X server (running on integrated graphics). (PS: This is possibly an inaccurate lay man summary of things, as is most of this howto .) This method also has its advantages - it is easy to switch off the discrete card using "vga_switcheroo" (described later) and turn it on when required. However, the graphics performance seems to be (only) on par with the Intel graphics - I think possibly due to the current state of mesa and drivers. Applications like glxgears run at half speed (250fps on radeon compared to 500 fps on intel, both on VirtualGL), although applications like Doom 3 run pretty much the same (about 20 fps at 1600x900), with the radeon being slightly faster and offering smoother frame rates. Another issue is that I think the image quality on discrete graphics is somewhat lower, possibly due to the image compression scheme(s) used by VirtualGL (which is geared towards efficient compression for transporting over networks).

I could not get to use fglrx using VirtualGL and also couldn't get to use open source radeon drivers to drive the primary X server. While I have tested things on my notebook, which is a Sony Vaio S 13.3 (VPCSA3AFX), these methods should work on similar notebooks with the only possible change of PCI Bus ID of the discrete graphics device (as described further along). Both driver methods are now described in some detail.

Method 1: ATI proprietary drivers (fglrx) method:

This method is fairly straight forward. In a nutshell, the system intially boots up with the Intel i915 driver running the display. But the X server is started with the fglrx driver that works in combination with the userspace component of the Intel drivers (xf86-video-intel) to do the actual graphics processing on the discrete GPU (and transferring the images to the Intel GPU, which is in turn the only device connected to the display outputs).

Hence, the first thing we need is a standard Intel graphics software stack - a recent kernel with i915 drivers, the xf86-video-intel package, with version <2.16 (preferably =2.15*) and a recent mesa and libdrm. The kernel configuration and other details are described later while discussing the second method that uses opensource drivers. The significant detail is that the i915 drivers should be preferably built into the kernel image, instead of being modular. (Even if built modular, it should be loaded before fglrx, perhaps using a initramfs. As explained later, the opensource radeon drivers in the kernel, if built, should preferably be modular and disabled at start using the option "radeon.disable=1" in the bootloader kernel commandline). Regarding the xf86-video-intel package, it is important to use a version <2.16, as was fortunately noted in the forum post [5] (by bojojo2020). This is because the current version of ati-drivers, 11.12 doesn't seem to work with newer versions of xf86-video-intel. (I was initially unsuccessful with 2.17, and in my opinion, this is perhaps the only detail due to which someone would fail in getting fglrx running.)

The rest is along the lines of what is described in the forum [5] and the Gentoo Wiki [6]. Here is a short summary. One emerges ati-drivers, preferably the latest 11.12 (as of now):

Code:

# emerge -av ati-drivers

. Then to use ATI's OpenGL libraries, the usual:

Code:

# eselect opengl set ati

. One may or may not need to run the ATI driver's initial configuration:

Code:

# aticonfig --initial

, which would create a new /etc/X11/xorg.conf, backing up the old one. This can be replaced with the one shown:

. An important detail is the bus ID line in the device section. Replace that with the corresponding bus ID of the graphics card on your system by looking at the "lspci" output for the ATI graphics card (and replacing periods with colons):

to get fglrx use the discrete GPU. With this, (re)starting the X server should have the discrete GPU doing the rendering work. The "glxinfo" should show up the ATI's openGL libraries. And if using AMD's OpenCL SDK (APP or Stream as it is called), "clinfo" should show the ATI graphics card available.

To use the Intel graphics subsequently, reverse the changes made earlier. We do

Code:

# aticonfig --px-igpu

to change to integrated Intel GPU. (This should not be required if using the intel driver in xorg.conf, and is also convenient not to do if one switches often between ATI and Intel Graphics.) We revert to mesa OpenGL:

. The next X server start (or restart) should make the system run on Intel GPU.

It is helpful to write scripts for these various actions, for example [6]. It may also be possible to do a more seamless switching between the integrated and discrete graphics cards as is done in Windows systems. While it may be still required to restart the X server, it would perhaps be possible to use the same xorg.conf. The ATI Catalyst Control Center, (the settings manager for fglrx) has a section for hybrid graphics, which may be useful.

Method 2: Open source drivers (radeon) method:

This method follows exactly along the ideas of the "Bumblebee" [2] and "Ironhide" [3] projects that are meant for similar muxless Intel/Nvidia hybrid graphics system. While these two projects are explicitly meant for Nvidia hybrid graphics, the methods easily extend to ATI hybrid graphics as well. The following is a summary of such an attempt by me on my computer, and also attempts to provide some information about how it works, since I could not find much documentation on the web. The technique is simple, yet novel -- to start a second X server on the discrete graphics card, and then use VirtualGL to run (i.e., render) 3D applications on the secondary X server, while outputting the final images to the primary X server (that runs on the integrated card). See the VirtualGL project at [4] for a fascinating reading.

Here we go about the details.

2.0. Prerequisites:

We need to have pretty recent kernel and X packages. For example, on my system, I have the following relevant packages:

2.0.1 kernel: For kernel, while I am using "helium-sources", the standard "gentoo-sources" or "vanilla-sources" >= 3.1 should do. The package "linux-firmware" or "radeon-ucode" is required for supplying firmware for the latest radeon graphics cards. The appropriate firmware files should also be referenced in the kernel config as explained further. In the kernel configuration, select "i915" driver (for intel graphics) to be built into the kernel, and the "radeon" driver to be modular:

Code:

CONFIG_DRM_I915=y
CONFIG_DRM_RADEON=m

. We also need the following for supporting hybrid graphics:

Code:

CONFIG_VGA_SWITCHEROO=y
CONFIG_DEBUG_FS=y

. While the vga_switcheroo (and a host of other drivers and features like acpi, hwmon, i2c, mxm, wmi, agp, drm etc) should be automatically pulled in, the debugfs feature needs to be selected explicitly.

For referencing the appropriate firmware files, the following kernel config options need to be set as below:

Blacklist the "radeon" kernel driver module in /etc/modprobe.d/blacklist.conf by adding the line:

Code:

blacklist radeon

, or blacklist it via kernel command line (in the bootloader configuration as explained further). This is to ensure that the intel driver for integrated graphics is loaded and used, and the radeon driver is not loaded automatically by udev at startup. Some additional options may be passed in the kernel commandline via the bootloader configuration as shown in the example below for grub2:

. The options "video=uvesafb:off video=vesafb:off" are used for disabling Vesa and Uvesa drivers for startup screen. The options "i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1" are useful for the laptops with latest Intel "Sandybridge" graphics (2nd generation "Core i3/i5/i7" processors), without which the CPU runs hot. The option "modprobe.blacklist=fglrx,radeon" are used for prevent loading automatically the radeon (in-kernel opensource driver) and fglrx (ATI's proprietary drivers) modules for the discrete graphics card. (The option "pcie_aspm=force" is currently required to force additional power management on most computers, and shouldn't be required in future kernel versions, possibly 3.2 and surely 3.3. The option "ikms=1" are specific to my setup since in my kernel config, the "i915" driver is compiled as modular, and is loaded by the initrd conditionally by this kernel commandline option. The option "xdriver=xorg" is also specific to my setup and is used by the custom gpu-detection scripts, that are similar to ones in Sabayon Linux distribution.)

2.0.2 X and mesa: The "xf86-video-intel", "xf86-video-ati" and "xorg-server" package versions on my system are currently in the stable portage tree. If not planning to use fglrx, it is better to use the newer xf86-video-intel packages, say 2.17, with USE="dri sna" -- the performance is better, uses the newer SNA (sandybridge) driver architecture, and power management also seems to be better. For the "mesa" and "libdrm" packages, while the stable (or ~arch) versions in portage should suffice, it is better to get the git versions, either by unmasking the corresponding 9999 packages in portage or even better by using the x11-overlay versions.

At this stage it is expected that one has the integrated Intel graphics fully functioning with proper 2D and 3D graphics acceleration (see the output of "glxinfo") and power management.

On some systems, for example on my Sony Vaio, the discrete graphics card is powered on by default and keeps consuming power, which apart from increasing battery usage, also raises the system temperature. It can be powered down when not in use (and I would highly recommend to do so) by loading the radeon module and using the debugfs interface of vga_switcheroo as follows:

Code:

# modprobe radeon
# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

. These two commands can also be added to a startup script, say /etc/local.d/misc.start. Another alternative for powering down the radeon is to emerge the package "acpi_call" and use it for passing a DSDT call for powering down the graphics card. The DSDT command is specific to the laptop bios. For example, on my Sony machine (do not try this on non-Sony machines, although it should just fail safely):

. For trouble shooting, one may look at the appropriate kernel log messages ("dmesg" command). On my machine, both methods seem to offer similar power savings, although I prefer the radeon and vga_switcheroo method. If I use the acpi_call method, after disabling and reenabling the card, if I try to load the radeon module, the system becomes unstable and mostly hangs. It is safe not to run the acpi_call when the radeon (or fglrx) module is loaded. It also seems that unloading the radeon module causes the system to become unstable and hang. However, using vga_switcheroo to turn the discrete graphics on and off doesn't cause any issues.

2.1. Running second X server on the discrete GPU:

Create a seperate X config file, say /etc/X11/xorg.conf.pxp and explicitly specify the bus ID of the discrete GPU in the device section:

The whole process can be scripted for automatically powering on the GPU and starting a X server for running a 3D application, and cleaning up afterwards. The bumblebee project offers such scripts like "optirun" for Intel/Nvidia systems. One may reuse most of such scripts with minor changes. One such crude script is shown below:

, which may be copied as /usr/local/bin/pxp_run.bash and made executable. Beware that it extremely crude. In particular, it expects the radeon xorg.conf shown earlier to be present at /etc/X11/xorg.conf.pxp. It also has a couple of sloppy sleep commands to wait for the application and X server to shut down before powering down the GPU.

Thank you very very much for your infos. I really think your HowTo shoud be put in the official gentoo wiki http://wiki.gentoo.org/wiki/Main_Page ._________________x11-drivers/ati-drivers co-mantainer
Yes i'm the #gentoo-it official ricer. --omg-optimized FTW!

Thanks for the information!
Could this howto be used to get the external graphic card from a sony vpc-z2 working?
That notebook has a dockingstation with an amd 6650m.
More information are in this bug report https://bugs.freedesktop.org/show_bug.cgi?id=41265

Great guide. I followed the first method and got the GPUs to switch. However, the power usage I'm seeing is not as good as I expected. If I use the open source radeon driver and echo OFF > /sys/kernel/debug/vgaswitcheroo/switch, the power usage is ~12-13W (in /sys/class/power_supply/BAT0/power_now), which gives me more or less the same battery life as Windows 7. However, when using fglrx and after aticonfig --px-igpu (and restarting X), I see the consumption is around ~18W (50% more!).

Do you see the same power usage when using fglrx and choosing igpu as when using xf86-video-radeon and disabling the card via vgaswitcheroo?

(edit) Scratch that; I'm getting 11W now with fglrx. Must have been the CPU.

I've build new vanilla kernel, add support for intel graphics, make it use kms as default, blacklist radeon and fgrlx. Than rebuild all drivers for new kernel.
All that work was done in a VT.

I've modprobbed manually fgrlx after reboot, have made aticonfig --px-dgpu. and have tried to startx. It fails (several times as I perform several tries ) and there are some thoughts about it further.

There were some usual errors on dri and dri2 not found (drm is now in kernel)

fgrlx was clever enough to start intel driver. Seemed fgrlx took screen0 for itself and leave the intel driver screen1. But intel was incapable to run and failed with (EE) Screen 1 deleted because no matching config section. So fgrlx was unable to continue functioning and stop self existence with a segmentation fault at address 0x4.

I've concluded that I should blame xorg and xorg.conf for incapability with fgrlx driver. Maybe other versions of xorg tolerate simple xorg.conf generated by aticonfig --initial, but my one just complains about Screen1 not configured in xorg.conf

Sorry for the late replies as I probably got unsubscribed from this thread after it was moved from unsupported to tips.

@gyhor: I think it should work, given that the ATI card does show up on the pci bus (according to the lspci info in the bug report). The best bet is to use fglrx (ati proprietary) drivers and specify the busid in xorg.conf appropriately as mentioned in the howto. In this case, for example, it seems to be "PCI:16:00:0" from the bug report.

@fran: Nice that it works. I haven't tried out the aticonfig with --px-igpu or --px-dgpu. I have it always set to discrete. May be I'll try that out so that I don't have have to switch xorg.conf as well. Frankly, I mostly stick to the intel xorg.conf and disable the ati card by loading the radeon driver and vga_switcheroo. Only rarely when I require, I use the ati drivers. I also get a faint but noticeable lag with fglrx. I'll check if --px-igpu can resolve that (instead of using the intel driver).

My power usage is 9 to 11 W on battery when using only the intel driver and discrete gpu switched off -- battery life is 5 to 6 hours, which is awesome for me. Haven't checked with fglrx, but the system temperature is up to 50-55 C compared to 40-45 when on intel driver.

@ayvango: The safest and easiest way is to use fglrx. Have the intel driver with kms compiled into the kernel. You also need xf86-video-intel package, compiled with USE="-sna". Currently, the ati-drivers-12.1 do work with xf86-video-intel-2.17. The older 11.12 drivers only work with 2.15. You need to specify the bus id of your card as mentioned in the howto and also in the earlier post above by fran. Also, the opengl needs to be set to ati (eselect opengl set ati) and I think without that, the X doesn't start. If things don't work, please post a little more of the end of your Xorg.0.log where the error occurs. Lastly, I have xorg-server-1.10.4, although I think that should not matter._________________Helium Sources || Gentoo Minimal Livecd

@ayvango: Thanks and I really hope that fglrx supports sna in near future, since apparently the sna driver architecture has better performance and power saving. Aside, when I got this laptop, I had given up all hope of getting the muxless radeon to work in Linux, but the fglrx support for hybrid graphics (down to the interface in catalyst control center) pleasantly surprised me, given that ATI is usually behind Nvidia in terms of Linux support._________________Helium Sources || Gentoo Minimal Livecd

@gyhor: You may look at your /var/log/Xorg.0.log. Alternatively, look at the changelog of the repository or ask the maintainer directly. For example, the changelog from Ubuntu packages website is here and doesn't mention about sna.

You may have better luck with the stock oneiric intel driver, which is still at 2.15. You may also provide the output of your "lspci -nn", "lsmod" and the file /var/log/Xorg.0.log (if X startup fails, the older log is at Xorg.0.log.old) for some additional help._________________Helium Sources || Gentoo Minimal Livecd

@gyhor: I am not sure as to why the BusID in the generated xorg.conf is "PCI:22:0:0", even though the lspci output shows "16:00.0". You can therefore try replacing the BusID in xorg.conf with "PCI:16:0:0" and see if you get the same error in Xorg.0.log. You may also use the simpler xorg.conf mentioned in the howto for fglrx (of course with the replaced PCI ID)._________________Helium Sources || Gentoo Minimal Livecd

I tried different xorg.conf configuration: minimal, with busid 16, with busid 22. everytime the same error message.
I don't know why the driver is looking on busid 22 for the card
But I am not the only one: https://bugs.freedesktop.org/show_bug.cgi?id=41265

I've build new vanilla kernel, add support for intel graphics, make it use kms as default, blacklist radeon and fgrlx. Than rebuild all drivers for new kernel.
All that work was done in a VT.

I've modprobbed manually fgrlx after reboot, have made aticonfig --px-dgpu. and have tried to startx. It fails (several times as I perform several tries ) and there are some thoughts about it further.

There were some usual errors on dri and dri2 not found (drm is now in kernel)

fgrlx was clever enough to start intel driver. Seemed fgrlx took screen0 for itself and leave the intel driver screen1. But intel was incapable to run and failed with (EE) Screen 1 deleted because no matching config section. So fgrlx was unable to continue functioning and stop self existence with a segmentation fault at address 0x4.

I've concluded that I should blame xorg and xorg.conf for incapability with fgrlx driver. Maybe other versions of xorg tolerate simple xorg.conf generated by aticonfig --initial, but my one just complains about Screen1 not configured in xorg.conf

Then I did reboot, but X failed to start, while trying to launch it with a tty console X always shows me this error :
(EE) Screen 1 deleted because no matching config section.
..........
segmentation fault at address 0x4.

I deleted /etc/X11/xorg.conf, then entered startx and Xorg was able to start but not with fglrx. I tried to edit manually my xorg.conf but nothing works.
Actually when the xorg.conf that aticonfig --initial created is present I can switch between the 2 gpu with aticonfig --px-igpu or aticonfig --px-dgpu so the driver switch works, the GL libraries switch works too. But with this xorg.conf present X fails to start. I also checked the PCI thing in xorg.conf and the one generated is good and correspond to my ATI 6630M PCI port.

What can I do ? Did I miss something to do ?
Are there others Intel packages I should compile with --enable-sna option ?

Excellent guide - I have everything working on a HP dv7 w/ a ATI 7690. Right now I just log in and use startx. When I try to exit back to the console, it just freezes with a black screen - can't do anything except turn power off then on. Anyone else have this problem and / or suggestions for a solution? Thanks!

EDIT/UPDATE - It appears not to be a problem with drivers, but with twm (ugh) which I first installed while following the Xorg install guide. I jeust put open box on, and I can log out of it with no problems. Thanks again for the info above!

you should not use sna, fglrx doesn't support it. Try to compile with --disable-sna

I've tried recent ati-drivers (12.6^d) with newest intel driver (>2.20). It doesn't work. It is still working with 2.19 driver. gentoo users may mask this intel drivers version to avoid X server failures.

Thanks for verifying that. Last time I checked (with intel-2.19.0 and fglrx-12.4), SNA was still not working. So I was a little confused when I came across an Ubuntu forums howto that says to enable SNA, but didn't have the opportunity to follow up on that._________________Helium Sources || Gentoo Minimal Livecd

Hybrid Graphics is still in experimental state for Linux. Xorg Developers have developed a technology called PRIME that can be used for switching between integrated and muxless discrete GPU at will. Automatic switching is not possible at the moment.

In order to use PRIME for GPU switching, make sure that you are using Linux Kernel 3.4 or later (recommended). You will need latest DRI and DDX drivers for your hardware and Xorg Server 1.13 or later with an optional patch applied.

Xorg Server should load both GPU drivers automaticaly. In order to run a GLX application on a discrete GPU, you will need to export the DRI_PRIME=1 environment variable. For example,

glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
303 frames in 5.0 seconds = 60.505 FPS
301 frames in 5.0 seconds = 60.113 FPS

With DGP powered off:

Code:

DRI_PRIME=1 glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
11550 frames in 5.0 seconds = 2309.990 FPS
11588 frames in 5.0 seconds = 2317.498 FPS

With DGP powered on:

Code:

DRI_PRIME=1 glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
22764 frames in 5.0 seconds = 4551.014 FPS
22661 frames in 5.0 seconds = 4532.134 FPS