Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs

[psychok9]

I've found an guide for old driver like this (modified from me):

git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
git branch -b origin/evergreen_accel
git checkout evergreen_accel

./autogen.sh
./configure --prefix=/usr
make
sudo make install

It's correct for activate alpha accelleration on X?
Some more options on xorg.conf?

[rohcQaH]

How I can compile R800 support on Ubuntu Maverick? I like to try and test it.

I'm using gentoo, but these are the general steps. If some of them seem unclear to you, you may be better off not installing an experimental driver in the first place

- get rid of fglrx if possible. At the very least, you must be able to boot without loading fglrx.ko, and fglrx's opengl libraries must not conflict with mesa's.
- install the firmware package. Check /lib/firmware/radeon/ if it's installed already. For evergreen, there's three files for each GPU type. Check wikipedia if your model is cedar, cypress, juniper or redwood (or just include them all).
- install kernel 3.5.35 or later, activate radeon DRI and KMS. Either compile them as modules, or force your kernel to include the firmware.
- install mesa git from last saturday or newer. If you're lucky, there's a package on PPA. Disable gallium, evergreen support is classic mesa only.
- install radeon, evergreen branch. I suggest installing to something like /opt/evergreen/ (create that directory first) to avoid messing with system files.

git clone 'git://anongit.freedesktop.org/xorg/driver/xf86-video-ati'
cd xf86-video-ati
git co evergreen_accel
./autogen.sh --prefix=/opt/evergreen/
make
sudo make install

- adjust xorg.conf to search the module where you installed it. You need to change the ModulePath

Section "Files"
    ModulePath "/opt/evergreen/lib/xorg/modules,/usr/lib/xorg/modules"
    ...

Make sure you understand each step so you'll be able to undo what you've done. The driver isn't stable, expect some corruption and xorg crashes.
Good luck.

[psychok9]

Very thank you for your help!!!
Before read your post, I've tried this

git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
git branch --track atombios-support origin/atombios-support
git checkout atombios-support

./autogen.sh
./configure --prefix=/usr
make
sudo make install

Modified with evergreen_accel I got 3D support (with some corruption but I'm happy anywat).

Now I'll try to clean up (roll back) and use your clean method.
I really appreciated your help

[Nille]

[SNIP]

I hope you not used the atombios-support branch. He is 3 Years old. You need evergreen_accel

[psychok9]

I hope you not used the atombios-support branch. He is 3 Years old. You need evergreen_accel

Of course

Seem very unstable, 1-2 mins and I got crash.
Mouse cursor corrupted... I can move windows without get tearing!

[psychok9]

git co evergreen_accel

/xf86-video-ati$ git co evergreen_accel
git: 'co' is not a git command. See 'git --help'.

What do you mean with "co"?

[nanonyme]

Probably local alias for checkout. Used for changing active branch in git.

[allquixotic]

Using today's git master of all Xorg libs, protos, server, mesa drm, and mesa/mesa. Linux 2.6.36-rc2-git3. Have a HD5970. Fully preemptible 1000 Hz. drm and radeon modules built-in to kernel.

Boot-up takes an extremely long time to switch to the KMS framebuffer. On the dmesg I see:

[   62.288248] r600_cp: Failed to load firmware "radeon/CYPRESS_pfp.bin"
[   62.288309] [drm:evergreen_startup] *ERROR* Failed to load firmware!
[  123.205570] r600_cp: Failed to load firmware "radeon/CYPRESS_pfp.bin"
[  123.205611] [drm:evergreen_startup] *ERROR* Failed to load firmware!
[  123.205645] radeon 0000:05:00.0: disabling GPU acceleration
[  123.206744] radeon 0000:05:00.0: ffff8801b653b400 unpin not necessary
[  123.206769] radeon 0000:05:00.0: ffff8801b653b400 unpin not necessary
[  123.206799] failed to evaluate ATIF got AE_BAD_PARAMETER

Later on, in Xorg.0.log, I see

[   464.362] (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS
[   464.362] (II) Loading sub module "shadow"
[   464.362] (II) LoadModule: "shadow"
[   464.362] (II) Loading /usr/lib64/xorg/modules/libshadow.so
[   464.368] (II) Module shadow: vendor="X.Org Foundation"
[   464.545] (II) RADEON(1): GPU accel disabled or not working, using shadowfb for KMS
[   464.545] (II) Loading sub module "shadow"
[   464.545] (II) LoadModule: "shadow"
[   464.546] (II) Reloading /usr/lib64/xorg/modules/libshadow.so

I've therefore got no 3d accel, but 2d accel is nice and stable, and actually quite fast, even with the core set to its minimum clock frequency using the power management profiles. Verified:

# cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 725000 kHz
current engine clock: 399990 kHz
default memory clock: 1000000 kHz
current memory clock: 1000000 kHz
voltage: 1000 mV

I've got both DVI outputs plugged into an LCD; could this be related to using dual monitors?

FWIW, the firmware seemed to have worked with 2.6.35.3, but I was still stuck in software rendering. I had a lot of different variables there though, such as building drm and radeon as modules.

Right now I'm going on 45 minutes running X without a crash, but since it's a shadowfb on top of KMS, this isn't very surprising; developers have presumably been testing this configuration for months while 2d/3d support was in the works.

And yes I'm using evergreen_accel. No xorg.conf.

[allquixotic]

Just changed my xrandr configuration from mirror (both monitors running at 1680x1050) to non-xinerama dual head (24" running at 1920x1200, 22" running at 1680x1050). Works like a charm.

What the heck is this shadowfb doing providing such smooth 2d accel? It's not allowed to be faster than fglrx! :P

Now if only I could get DRI2 to work... I guess I need to get the firmware working first, don't I.

[V!NCENT]

What the heck is this shadowfb doing providing such smooth 2d accel? It's not allowed to be faster than fglrx! :P

Well the point is that shadowfb is doing almost nothing; only blitting and drawing some shit on RAM and then sending it happily to the framebuffer.

Now if you'd be doing more than just this crap it would be more efficient per time to send it all over tot the graphics card, which takes time, and let the GPU handle all that stuff.