14 thoughts on “HowTo: RadeonHD 4550, Gallium3D, UT2004”

1. Awesome post!

2. Is there a way to also build the 32bit version for those of us on AMD64 wanting to use this with WINE or with other 32 bit binaries?

   I had ran into this trying nouveau for an nvidia card in one of my boxes.

   • There are plenty of tutorials out there for building 32-bit binpkgs, usually with chroots. You already have 32-bit versions of the regular, stable libraries installed, as long as you built emul-linux-x86-xlibs with +opengl.

3. Thanks for the guide. It misses one important thing though. The firmware blob:

   emerge x11-drivers/radeon-ucode

   Then you need to configure the kernel to embed the firmware binary during building. The setting is in “Device Drivers->Generic Driver Options”:

   [*] Include in-kernel firmware blobs in kernel binary
   (radeon/R700_rlc.bin) External firmware blobs to build into the kernel binary
   (/lib/firmware) Firmware blobs root directory

   We are not done yet. Games and application that make use of S3TC (S3 texture compression) don’t work, or work slower. To fix this, we need to install libtxc_dxtn. Sadly, it’s not in portage. But an ebuild can be found here: http://bugs.gentoo.org/show_bug.cgi?id=65607

   After installing libtxc_dxtn, we need to tell the r600 Gallium driver to use it. This is done by an env var. Edit your /etc/env.d/99local and append this:

   R600_ENABLE_S3TC=1

   Now run ‘env-update’ and restart X. S3TC should now be supported. Here for example, if I run VMWare Workstation and have Windows Vista or 7 installed in it as a guest, I can now activate Aero and it will work. Many games that previously only ran with fglrx under Wine will now also work with the FOSS driver.

   We’re not done yet. Mesa does not support floating point textures. But if you use mesa-9999, it does. But you need to build it with the “bindist” USE flag disabled. In other words, in your package.use:

   media-libs/mesa -bindist

   After you rebuild mesa, floating point textures will be supported. That means even more games in Wine should work, as we now have much better OpenGL conformance.

   • very useful comment for me, thanks a lot

4. PS:
   To verify that S3TC and FP textures are supported, this command:

   glxinfo | grep 'float\|s3tc'

   Should print:

   GL_NV_texgen_reflection, GL_NV_texture_env_combine4, GL_S3_s3tc,
GL_EXT_texture_compression_s3tc, GL_EXT_texture_env_dot3,
GL_ATI_draw_buffers, GL_ATI_texture_env_combine3, GL_ATI_texture_float,
GL_ARB_half_float_pixel, GL_ARB_occlusion_query2, GL_ARB_point_sprite,
GL_ARB_texture_float, GL_ARB_texture_rectangle,
GL_ATI_texture_compression_3dc, GL_EXT_packed_float,
GL_ARB_half_float_vertex, GL_ARB_instanced_arrays,

5. You are wrong in the -video_cards_radeon useflag…
   It just enables global support for all radeon families where you can finegrain it later by using r600.

   Gallium useflag control building of the gallium infrastructure, where classic useflag enables the old mesa code.

   Also for best performance llvm useflag should be seriously turned ON.
   32b libraries are handled in the package masked opengl package, where they should use latest trunk instead of the stable stuff.

   For the xorg.conf you should have EMPTY xorg.conf completely and just use xorg.conf.d for your special input device options if you need so.

   Also i wrote nice guide howto migrate from fglrx to radeon and it is on x11 project page.

   Those are just my 2c

   • Last I checked, all the radeon code for <r600g was still built when it wasn't explicitly disabled. I had multiple entries in the 'eselect mesa' output that I didn't need, so there was some hidden build going on, even when I only wanted the gallium/r600 code enabled.

   • An xorg.conf does indeed not exist at all here. And the “Mode 0666″ thingy is only needed for fglrx (and I’m not sure if it’s still needed anyway with latest fglrx versions.)

     • Wrong. It’s always been there exclusively for the free drivers:

       http://dri.freedesktop.org/wiki/DriTroubleshooting

       • You are correct. I guess I didn’t need it because my user is in the “video” group.

         ls -l /dev/dri/
total 0
crw-rw---- 1 root video 226, 0 May 15 20:13 card0
crw-rw---- 1 root video 226, 64 May 15 20:13 controlD64

6. My first reply some hours ago seems to have disappeared without ever appearing…

   Re: options that still work:

   See the recently updated radeon (4) manpage. It now has separate sections for kms, ums, and both, so it’s clear what options apply to each. It doesn’t appear to make a distinction between gallium and classic drm, however. Maybe the options listed apply to the ddx (which is still Driver “radeon”) regardless of which OpenGL driver, classic or gallium, is used? As for kms, there’s rather fewer options than ums, but that’s to be expected since kms is newer and doesn’t have the number of corner-cases to configure for, and also because with kms some of the options are kernel or module command-line options, now.

   Re: power management:

   With recent kernels (IIRC starting around 2.6.35 but that’s just a guess, and you’re talking .38, which should certainly have it), that can be configured “live” by poking the relevant sysfs files:

   /sys/class/drm/card0/device/power_*

   There are two files of interest, power_method and power_profile.

   power_method: two possible values:
   profile (default), dynpm (card hardware pm).

   If profile is set, then the power_profile file comes into play: four possible values:
   default
   low
   high
   auto (low/high depends on ac/batt).

   The defaults were formerly hardcoded to default profile.

   dynpm wasn’t considered stable as of first introduction, I believe because there were still assumptions in the code that the clock rate was under software control, so having the hardware change it out from under the software wasn’t yet the stablest option, but that’s probably improved some by now, and may at some point be the default at least for some chips.

   Obviously gamers may wish to set high for gaming, while laptop users and those worried about fan noise or overheating may prefer low.

   FWIW, I mainly use OpenGL for kde’s visual effects. I experimented a bit but eventually commented the entries I had in the script I was running (from local) at startup. But I left it and the comments I had explaining it to myself there for reference and referred to it for the explanation above.

   @ Cynyr: Yes, there’s a way to build the 32-bit on 64-bit. There might be an easier way, I’m not sure, but certainly, the 32-bit chroot method should work. Follow the links to the documentation for it from amd.gentoo.org . That’s probably overkill if that’s /all/ you want to do, but it’s certainly /possible/, and quite well documented, as well. I use a slight modification of that idea for the 32-bit chroot build-image for my netbook, which is then rsynced over so the netbook does no building or package installation at all. =:^)

   Duncan

7. Nothing to add that hasn’t already been said, but I’ve found fglrx hates my ~amd64 + zen-sources setup, so I’ve been using the open driver for months anyway. It’s fast enough to play minecraft + ut2k4 decently and that’s good enough for me (60fps would be nice though…)

8. “… slowdown and lower frames. This mostly occurs on very large, detailed maps…”
   I also noticed this when I tried UT2004 for a first time and I also noticed that under Windows same levels run a lot more smoother. (Running nvidia card at the time, so almost same speed with both OpenGL drivers).

   With little experimenting I seemed to had it figured out. You need to enable
   UseVBO=1 in the OpenGL section of ~/.ut2004/System/UT2004.ini .
   If I understand correctly this is used for vertex shaders.
   It have probably been disabled as some drivers may hang when using it, so you’ve been warned.

   (Yes, I know this post is one year old. Still, it may be useful.)

Comments are closed.