ATI R600/700 OSS 3D Driver Reaches Gears Milestone

[bridgman]

The drm support for 6xx/7xx EXA/Xv acceleration was merged in 2.6.30

DRM support for 1xx-5xx KMS was merged in 2.6.31

DRM support for 6xx-7xx KMS has not been merged, nor has support for 6xx-7xx 3D.

For 6xx-7xx 3D you still need to pick up the r6xx-r7xx-3d branch of agd5f's drm repository :

Building libdrm and radeon and drm kernel modules from git:

1. git clone git://anongit.freedesktop.org/~agd5f/drm

2. cd drm

3. git checkout -b r6xx-r7xx-3d origin/r6xx-r7xx-3d

4. ./autogen.sh --prefix=/usr

5. make

6. sudo make install

7. cd linux-core

8. make drm.o radeon.o

9. copy the new modules into your kernel tree. Depending on your kernel, either:

sudo cp drm.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/
sudo cp radeon.ko /lib/modules/`uname -r`/kernel/drivers/char/drm/

or:

sudo cp drm.ko /lib/modules/`uname -r`/kernel/drivers/gpu/drm/
sudo cp radeon.ko /lib/modules/`uname -r`/kernel/drivers/gpu/drm/radeon/

10. sudo depmod -a

[pingufunkybeat]

Thank you.

I thought I had read somewhere that you didn't need that anymore since the latest git snapshot of 2.6.31, but it's likely that several people (including me) were confused there.

[kernelOfTruth]

Thank you.

I thought I had read somewhere that you didn't need that anymore since the latest git snapshot of 2.6.31, but it's likely that several people (including me) were confused there.

afaik the kernel-merge for 2.6.31 is (only) referring to the r500 chipsets ...

edit:

ah - yes:

DRM support for 1xx-5xx KMS was merged in 2.6.31

[bridgman]

Yep, it does get confusing because there are so many different projects going on at the same time; some have been merged upstream but others are still in branches.

The good news is that the projects everything else depends on (KMS/GEM/TTM) are catching up with and overtaking the projects which depend on them

[some-guy]

Did you try 'LIBGL_ALWAYS_INDIRECT=1 compiz --replace --indirect-rendering ccp' ?

[nanonyme]

That sounds redundant. LIBGL_ALWAYS_INDIRECT=1 has the same effect on compiz as --indirect-rendering afaik. You only need one, not both.

[kernelOfTruth]

yes I did try that

in fact he full command I am / was experimenting with was:

compiz --replace ccp --sm-disable --indirect-rendering  --ignore-desktop-hints &

strangely there's a lot of corruption when entering text, if you move the window where it was entered afterwards (afaik) it looks fine

the only compositing which runs (almost) reasonably fast and stable is kde 4.3 with kwin + Xrender


kwin + opengl or compiz(-fusion) both lead to corruption / artifacts on the display

it also doesn't seem to be very "stable":

there are some lock-ups of screen output (e.g. when enabling compositing manager function of metacity and launching awn the screen content doesn't update at all), sometimes it crashes X after a while during high load (e.g. googleearth), sometimes it hardlocks with flashing num- and oder lock-lights

sometimes it even turns the screen black there's a lot of corruption

in most of the cases it then can be rebooted via magic sysrq key

thanks guys

your works is highly appreciated

[nanonyme]

strangely there's a lot of corruption when entering text, if you move the window where it was entered afterwards (afaik) it looks fine

That's a common issue

the only compositing which runs (almost) reasonably fast and stable is kde 4.3 with kwin + Xrender

Compiz is now nice and fast for me with latest Mesa and DRM updates. (including the optimized blitting)

there are some lock-ups of screen output (e.g. when enabling compositing manager function of metacity and launching awn), sometimes it crashes X after a while during high load (e.g. googleearth), sometimes it hardlocks with flashing num- and oder lock-lights

I didn't try it that extensively but didn't notice any lockups myself.

sometimes it even turns the screen black but then can be rebooted via magic sysrq key (e.g. when running openarena)

OpenArena has so horrible corruption for me anyway that I'd consider it unplayable. It's damn fast though.

[legume]

That sounds redundant. LIBGL_ALWAYS_INDIRECT=1 has the same effect on compiz as --indirect-rendering afaik. You only need one, not both.

I noticed I had both set for my old compiz, which I last used when I had a R500 card.

Although with my R6xx compiz is quite borked, testing shows there is a difference between using the export and the --indirect-rendering. With the latter alone 3D apps get direct rendering, so are fast but will remain in place if you rotate the cube.

With the export/both then they will render indirectly, so slower, but will try to move with the cube. (doesn't render for me, but then not much else does very well either).

[nanonyme]

Right. Well, it's not like compiz is that much fun without DRI2 anyway. (the behaviour you described pretty much sounds like describing the DRI1 limitations to me)