OSS Radeon is working finally

[FunkyRider]

I have a Radeon HD 2900XT lying in my cupboard for a long long time because I had truly terrible experience with fglrx drivers.

A week ago I took my GTX 260+ out of the main PC and poped the 2900XT back in for a test of how long has the OSS drive gone. The result is pretty good.

OS is Ubuntu 9.04 x64, driver is the one comes with Ubuntu
First impression from start up using 'radeon' driver:

GDM/Desktop appears very fast. A lot faster than any of those binary blobs.
Restart GDM is a second snap, instead of 20 seconds lock up waiting to end it process.
Desktop 2D responsiveness also a lot faster than fglrx/nvidia binary blobs. Window redraw, move, scroll all fluid and feels very 'light' - i.e. no lag at all.
Tear free textured video Works! yeah! Played several SD and HD video contents in mplayer, CPU usage is very low and graphics is smooth (both in image quality and tear free screen update)
Also tried metacity composting, all went very good. The only little issue is tear free does not work anymore under composite desktop.
Very stable, zero lockup, no scrambled screens.
Because it does not kick the GPU into 3D frequency/voltage, the fan works very quiet and outputs considerably small amount of heat (I BIOS modded my card to 0.9v, 325/500 in 2D).

The overall experience is very positive. I think when 3D arrives, I shall dump my GTX 260+ and go back to the old class 2900XT to enjoy OSS desktop.

Thank you for your great works!

[bridgman]

Try Option "EXAVsync" "on" in xorg.conf; that might help with video under compositing.

Of course it could also introduce enough delays to make things worse, which is why it defaults to "off" ;)

[Melcar]

Have you tried the radeonhd drivers? I find that they work slightly better on my HD4850. The one in Jaunty is rather "old", so it's best to get it from git:

https://help.ubuntu.com/community/RadeonHD

[FunkyRider]

Thanks for the updates.

Already tried the Option "EXAVsync" "on" options, still got tearing on composite XV. :-(

I will build the latest radeonhd and give it a go tonight.

[Boerkel]

I have a Radeon HD 2900XT lying in my cupboard for a long long time because I had truly terrible experience with fglrx drivers.

A week ago I took my GTX 260+ out of the main PC and poped the 2900XT back in for a test of how long has the OSS drive gone. The result is pretty good.

OS is Ubuntu 9.04 x64, driver is the one comes with Ubuntu
First impression from start up using 'radeon' driver:

GDM/Desktop appears very fast. A lot faster than any of those binary blobs.
Restart GDM is a second snap, instead of 20 seconds lock up waiting to end it process.
Desktop 2D responsiveness also a lot faster than fglrx/nvidia binary blobs. Window redraw, move, scroll all fluid and feels very 'light' - i.e. no lag at all.
Tear free textured video Works! yeah! Played several SD and HD video contents in mplayer, CPU usage is very low and graphics is smooth (both in image quality and tear free screen update)
Also tried metacity composting, all went very good. The only little issue is tear free does not work anymore under composite desktop.
Very stable, zero lockup, no scrambled screens.
Because it does not kick the GPU into 3D frequency/voltage, the fan works very quiet and outputs considerably small amount of heat (I BIOS modded my card to 0.9v, 325/500 in 2D).

The overall experience is very positive. I think when 3D arrives, I shall dump my GTX 260+ and go back to the old class 2900XT to enjoy OSS desktop.

Thank you for your great works!

Same here, but with a 2600. The free driver is really nice. But i wonder when we will see 3D finally? Weeks, months, years?

[pingufunkybeat]

I'm really happy with the 2D drivers and my HD 4550. Video works great, XRender effects are nice and fast, and the whole thing is very stable. However, I have a slight problem when I turn on compositing.

As soon as I do that, windows have trouble repainting. It's as if a paint event goes missing, whenever I switch windows (especially across desktops in KDE4), I get half-repainted windows and I have to move it around so it gets some paint events, after which it redraws fine.

I've googled all over and I haven't found anything similar to this.

I've checked out the git version of radeon, hoping it might be fixed, but it's still the same. Because of this, I usually turn compositing off. I'm running a 28 kernel with the drm module I also checked out from git, as per wiki instructions, some time in May. I don't think an old drm could be the culprit, or could it?

Another thing -- DynamicPM hard froze X when waking up from DPMS, so I turned it off.

Has anyone else experienced this?

P.S. I'd also like to add that open-sourcing drivers and releasing documentation is the main reason why I went with ATi instead of nVidia on my new system. I'm willing to accept some trouble on the way, as long as the result are free drivers. Once the 3D support gets decent, I'm planning to get a stronger card.

[jrch2k8]

Same here, but with a 2600. The free driver is really nice. But i wonder when we will see 3D finally? Weeks, months, years?
well i have a 4850x2 and i been testing latest git mesa work with the great help of bridgman and i can say they are really near to a usable DRM/DRI/Mesa 3D implementation so wait until mesa 7.6 release for 3D and maybe kernel 2.6.31 rc5 or something like that for kernel DRM support, aka maybe a couple of months

[Ex-Cyber]

Why would R600 DRM support show up in -rc5? Doesn't -rc mean that the merge window is closed?

[blackiwid]

as far as i am informed, 3d support is there right now, workable since few weeks, but the question ist how stable it is, and that could be better in a few weeks.

I hope to see in karmic koala in 1 or 2 weeks first 3d support. But what i not get with mesa 7.5 3d should be there why should we wait till mesa 7.6?

or did i got something wrong?

[BlackStar]

Why would R600 DRM support show up in -rc5? Doesn't -rc mean that the merge window is closed?

AFAIK, the DRM code made the merge window. It's a matter of stability now (by rc5 most bugs should have been ironed out).

[bridgman]

Ex-Cyber, I think the change was sufficiently low risk that it was considered OK for a non-final RC. AFAIK the Linux cycle is basically 2 weeks of merge and 11 weeks of RCs, so a lot of things go into RCs ;)

blackiwid; the 6xx/7xx 3d code is not in mesa master or drm master. It's largely coded but not really working yet, although I think we're getting close.

[Veerappan]

By not in master, are you referring to the following trees/branches?:

http://cgit.freedesktop.org/~agd5f/drm/log/?h=r6xx-r7xx-3d
http://cgit.freedesktop.org/mesa/mesa/log/?h=r6xx-rewrite

Or are there another set of repositories I should be refreshing every 20 minutes? :)

I've kept my eyes on:
http://cgit.freedesktop.org/mesa/drm/log/?h=r6xx-r7xx-support

But it looks like that branch has been gathering dust for a while.

[jrch2k8]

Same here, but with a 2600. The free driver is really nice. But i wonder when we will see 3D finally? Weeks, months, years?

like blackstar said the code is already there and it works, i said rc5 to give them some time to stabilize the code and get most bug ironed out before 2.6.31 release maybe the bigger wait time is mesa 7.6 cuz radeon/radeonhd is ready for primetime too and dri is providing accel already for video/EXA

[bridgman]

By not in master, are you referring to the following trees/branches?:

http://cgit.freedesktop.org/~agd5f/drm/log/?h=r6xx-r7xx-3d
http://cgit.freedesktop.org/mesa/mesa/log/?h=r6xx-rewrite

Yep, those are the ones.

like blackstar said the code is already there and it works, i said rc5 to give them some time to stabilize the code and get most bug ironed out before 2.6.31 release maybe the bigger wait time is mesa 7.6 cuz radeon/radeonhd is ready for primetime too and dri is providing accel already for video/EXA

D'oh !! You were talking about 2.6.31 RC5; I think the 6xx/7xx 2D drm support went in around RC5 of 2.6.30, so I was talking about past tense stuff ;)

Yeah, the main thing is that we don't want to push the drm support in until there's a demonstrably working mesa driver to use it, so we have some confidence the API doesn't need to change from that point on.

[Veerappan]

Yep, those are the ones.

Sounds good. I'll give them a shot sometime when it doesn't matter if I render my desktop unusable (which I do often enough as it is). :)

[gd_19]

Sounds good. I'll give them a shot sometime when it doesn't matter if I render my desktop unusable (which I do often enough as it is). :)

lol.. same here.. i spend more time stuck with a vga console than with a decently accelerated X server :-D

So if I understand correctly, in order to test the latest open source ati stuff on R600 one needs:

1) 2.6.31-rc1 patched with radeon DRM and TTM
2) libdrm from the r6xx-r7xx-3d branch
3) the r6xx-rewrite branch of mesa
4) the kms-support (?) branch of xf86-video-ati?
5) dri2proto

[FunkyRider]

latest radeonhd gives me screen corruption when switching windows... Switched back to radeon and all went good :-(

[bridgman]

lol.. same here.. i spend more time stuck with a vga console than with a decently accelerated X server :-D

So if I understand correctly, in order to test the latest open source ati stuff on R600 one needs:

1) 2.6.31-rc1 patched with radeon DRM and TTM
2) libdrm from the r6xx-r7xx-3d branch
3) the r6xx-rewrite branch of mesa
4) the kms-support (?) branch of xf86-video-ati?
5) dri2proto

Actually, if you want to start trying 6xx/7xx 3D you kinda need to go the other way :

- 2.6.28 kernel or earlier
- drm from ~agd5f/drm r6xx-r7xx-3d branch
- radeon (or probably radeonhd) from master
- mesa from 6xx-rewrite branch

6xx drm support for X server (EXA/Xv) and <6xx KMS/GEM/TTM are in the kernel upstream tree (so you need to use relatively new code) but 6xx 3D drm support hasn't gone upstream yet and is living in a branch of fdo mesa/drm so you need to stay with older kernel code for now.

[pingufunkybeat]

So I guess I'm the only one who has problems using composite with R600+ hardware? :confused:

[forum1793]

I just tried with XRender Compositing type with kde4.2 (I think) with hd3200 (780g) and radeonhd. Compositing basically works OK with the r6xx using XRender. Though I still think fglrx works better.

I also turned compositing back off. I never saw any real benefit to it.

[pingufunkybeat]

Actually, it looks like it could be a very obscure bug relating to KDE 4.2 and Qt 4.5, which only occurs when using EXA and compositing (on all xorg drivers, apparently).

Changing the widget style helps somewhat. Switching compositing off fixes it completely.