Thursday, 12 December 2013

AMD Catalyst fglrx driver and Open Source Radeon driver: Enjoy both on Gentoo Linux- Part 2

[Visit my earlier post for part 1]

In this post we will see how to install catalyst binary driver without uninstalling the open source driver and keeping both the drivers. Catalyst fglrx legacy driver is not support by Xorg higher than 1.12 and kernel versions 3.5. Although with specific kernel patch you can go till kernel 3.8 3 3.10.32.

Note: This post is updated to use with kernel 3.10.32 catalyst fglrx support. Depending on the kernel version used for the build, you should make necessary version changes in the scripts as applicable.

Configurations used for Catalyst fglrx binary driver

x11-base/xorg-server : 1.12.4-r1
x11-drivers/xf86-input-synaptics : 1.6.4
ati-drivers : 13.1_pre897
Linux kernel  : 3.8.13 to 3.10.32
Note : Portage already had patch for kernel 3.8.x to 3.10.x and it is pulled by the ebuild when you emerge ati-driver

Configurations used for Open Source Radeon Driver

x11-base/xorg-server : 1.14.2
x11-drivers/xf86-input-synaptics : 1.7.1
Linux kernel : version 3.12 (vanilla source build)

The key point to note is while emerging Xorg for fglrx , you need to specify a separate root and emerge by ignoring all dependencies. Just enough of the core Xorg-1.12 server package and input drivers(either evdev or synaptics).

While your actual system root is untouched and unaware of the older Xorg, eselect opengl does the rest by appropriately adjusting the symlinks of opengl libraries.

Now we can proceed with the installation.

Prepare for chroot :
mkdir /mnt/GENTOO
mount /dev/sda<partition no> /mnt/GENTOO
cd /mnt/GENTOO
mount -t proc proc proc/
mount -t sysfs sys sys/
mount --rbind /dev /mnt/GENTOO/dev
mount -t devpts pts dev/pts/
chroot /mnt/GENTOO /bin/bash
Note: Now from here onwards you are in chroot environment i.e. Gentoo Linux.
source /etc/profile

Create a separate root directory for fglrx & xorg-1.12 related packages
mkdir /mnt/fglrx
Portage configuration to enable legacy driver:
echo 'x11-drivers/ati-drivers:1' >> /etc/portage/package.mask 
Now emerge xorg-server
ROOT="/mnt/fglrx" CPPFLAGS="-I/mnt/fglrx/usr/include/xorg" emerge --nodeps =x11-base/xorg-server-1.12.4 x11-drivers/xf86-input-evdev x11-drivers/xf86-input-synaptics --oneshot --ask
Point default linux symlink to the kernel source(version 3.8.13 3.10.32)
cd /usr/src/linux
ln -s /usr/src/linux-3.10.32/ linux
Now you are ready to emerge catalyst legacy drivers, it will build against kernel-3.10.32
emerge -v ati-drivers:legacy --nodeps  --oneshot --ask

Note : If you get build fail while building fgl_glxgears, it is because of some missing header files & changes in newer version of mesa ATI files. Ensure you have mesa package installed.
Catalyst fglrx doesn't build with mesa version >8. If you are on Mesa-9 most likely the build will fail with the below error message:
x11-drivers/ati-drivers-13.1_pre897::gentoo failed (compile phase):
 *   fgl_glxgears build failed
The specific snippet of code:
 *       "$(tc-getCC)" -o fgl_glxgears ${CFLAGS} ${LDFLAGS} -DUSE_GLU -I"${S}"/${FOLDER_PREFIX}usr/include fgl_glxgears.c -lGL -lGLU -lX11 -lm || die "fgl_glxgears build failed";

Workaround for this problem is to provide Mesa-8 openGL files. To build the fglrx module with Mesa 8 without downgrading your current setup follow below steps:
emerge -v =media-libs/mesa-8.0.4-r1 --fetchonly
It will download MesaLib & associated mesa-patch files in portage directory.
cd to /usr/portage/distfiles
extract include/GL folder from MesaLib-8.0.4.tar.bz2.
Backup existing Mesa library header files
mv /usr/include/GL /usr/include/GL_Original_BAK
Now copy GL header files from Mesa 8 to /usr/include/ folder

Try emerge again. This time it should successfully build the module. If the build is successful, you can restore the original Mesa openGL libraries:
mv /usr/include/GL_Original_BAK  /usr/include/GL

Generate Xorg configuration files:
/opt/bin/aticonfig -i /dev/null -o /etc/X11/fglrx.conf --initial
Add the below section for fglrx modules in fglrx.conf:
Section "Files"
        ModulePath "/mnt/fglrx/usr/lib64/xorg/modules"
        ModulePath "/usr/lib/xorg/modules"

Xserver rc file (OpenRC based but works also with systemd )
Now we need to tweak xserverrc file, so it points to correct xserver modules when we change opengl through eselect opengl

If you are on full systemd support, you may not be having xserverrc file. If it does not exists, create it with the below content:

File: /etc/X11/xinit/xserverrc
if lsmod | grep -q "^fglrx\b"; then
eselect opengl set ati
exec /mnt/fglrx/usr/bin/X -config fglrx.conf -nolisten tcp "$@"
eselect opengl set xorg-x11
exec /usr/bin/X -nolisten tcp "$@"

Next you need to change the GDM scripts.

Ligthdm is the default GDM in Gentoo, change the configuration file to point to the modified xserverrc file

File /etc/lightdm/lightdm.conf:
Module blacklisting and Grub configuration
Now we need to blacklist opensource radeon driver module to prevent it from loading, when booting with kernel 3.8. Add the following commandline parameter to grub.conf .
linux   /vmlinuz-3.8.13.gentoo resume=/dev/sda15 root=/dev/sda8 modprobe.blacklist=drm,radeon ro init=/usr/lib/systemd/systemd
initrd  /initramfs-gentoo-x86_64-3.8.13
Note : The preferred way to generate grub2 is using grub-mkconfig -o /boot/grub/grub.cfg. I usually add it manually for my setup keeping in mind other linux distro and Windows OS that I have. If you run grub-mkcofig your changes will be gone, so keep that in mind.

Now you are ready to boot into Gentoo with Catalyst fglrx driver, but before that exit from chroot environment with the below cleanup stuffs for a clean shutdown behavior!
umount {proc,sys,dev/pts,dev}
umount /dev/sda8

Now boot into your Gentoo system with kernel 3.8.13 fglrx enabled, if all goes well you should have the X startup & GDM login window.

Check fglrx kernel module loaded properly and you have opengl working properly:
lsmod | grep -i fglrx
Check direct rendering:
glxinfo | grep -i direct
Check fglrx gears:

Hope this post helps if someone is trying to have both the Open Source version & Catalyst fglrx drivers together.
Read More

Saturday, 7 December 2013

AMD Catalyst fglrx driver and Open Source Radeon driver: Enjoy both on Gentoo Linux- Part 1

This guide is applicable for the owners of ATI Radeon R600 Series(Radeon HD 2XXX/3XXX/4XXX series). Last year AMD dropped support for these cards and moved it under legacy product category. So if you are upgrading your Linux distro, you are left with no choice than to use Open Source Radeon Driver.

The good news is that the gap between the open source and catalyst drivers are becoming narrow thanks to the recent Kernels and updated Mesa graphics stack.

Starting from kernel 3.11 which brings DPM(Dynamic power management) support for open source radeon driver. This feature is not enabled by default and you need to enable it from the grub command line or as a module parameter by passing this parameter "radeon.dpm=1".

Still the dynamic power management is not as good as compared to the Catalyst PowerPlay. The heat issue is still there and the gpu seems to work in high frequency even with light graphics intensive application and gets warm very soon. I've seen no difference even with Kernel 3.12.x series. The thermal management is still very poor with radeon open source driver.

Due to this I had kept my Ubuntu 12.04 LTS edition as it is, and not updating it any further while the other distribution Gentoo is more up to date(off course using with open source driver). I was wondering if at all there is possibility that both open source driver and catalyst binary driver can co-exist. Finally I came across this very good Gentoo Wiki which explains co-existence of both binary and open source driver. I thought to give it a try with my existing Gentoo distro.

Gentoo is very powerful and highly customizable distro and I've started liking it over my long term stable Slackware ever since I replaced it with Gentoo.

Over the next post I'll be explaining how to get it working on a 64-bit distro from a safe chroot environment! Gentoo wiki is for 32 bit version and I still had compilation issues while building the kernel module for fglrx but in the end I managed to get it working.

Now I've Gentoo running on AMD Catalyst binary driver with fully functional Gnome Shell(3.8) & KDE 4.10 with all the eye candy features supported ! What's more, I can also boot to the latest kernel with open source driver, and enjoy best of both open source and closed source Catalyst!
Read More

Friday, 6 December 2013

Android Kitkat 4.4 - Experience experimental ART Runtime Feature on SGS I9000

Android 4.4 brings experimental support for ART(Android Run Time) the alternative for Dalvik runtime. For curious novice, Dalvik is the VM that powers the android app, which are basically written in Java. The compiled byte code is interpreted by the Dalvik VM. A good background on Android Runtime Dalvik VM can be found here.

Dalvik VM has its own limitation, executing interpreted code is slower than native compiled code, it takes additional CPU power and in turn consumes more battery. Although with today modern processors, the difference is not all that striking but on a mobile platform it still counts a lot.

The future replacement of Dalvik, i.e. Android Runtime(ART) is included in Android 4.4 as an experimental feature. Dalvik is still the default runtime and the new ART runtime can be selected from the developer options.

To enable ART runtime, follow below steps:

Enable Developer Options(if not enabled)
Settings > About Phone > taps 7 times on build number

Enable Android Developers Options
Enable Android Developers Options

Settings > Developer Options > Select runtime > Use ART

Developer Options
Developer Options

select runtime
select runtime

reboot prompt
reboot prompt

Once the runtime is changed, it will prompt to reboot. Initial boot will be a lot longer as the application will be compiled again with the new runtime (

After the first boot it takes some to adjust with the new settings. Depending on the number of apps installed on the phone, your experience may vary. I feel it tends to take up more memory after some time of use. Some random restart also happen, but it's acceptable considering ART Runtime an experimental feature. It will definitely get better with future release and ART-compatible apps will utilize its full potential. 
Read More
Powered By Blogger · Designed By Seo Blogger Templates