Open-Source ATI R600/700 3D Driver Almost Working

[phoronix]

Phoronix: Open-Source ATI R600/700 3D Driver Almost Working

AMD's John Bridgman has shared that the open-source R600/700 3D driver for Linux is becoming usable, slowly but surely. Months after releasing documentation, a programmer's guide, and sample code, their Mesa driver is beginning to do useful things -- more so than just rendering simple triangles. The ATI R600/700 3D driver is derived from the Radeon driver rewrite and is currently living in a branch off of Mesa...

http://www.phoronix.com/vr.php?view=NzM2Mw

[NSLW]

What about usable 3D in games for older radeons? Will it be in good standing and usable by the end of summer or do all developers focus now on ATI Radeon HD 2000/3000/4000 series?

[FireBurn]

What about usable 3D in games for older radeons? Will it be in good standing and usable by the end of summer or do all developers focus now on ATI Radeon HD 2000/3000/4000 series?

A lot of work is going into the Radeon Gallium driver fro r300 and latter cards

[tmpdir]

Nice to see this stuff work opensourced

[JeanPaul145]

This is really good news to me.
It's still hard for me to project when the driver will actually be usable for end users (like myself), because AFAIK there's no info on the speed of the driver, and op top of that I don't know anything about how long it took the developers to get these test cases to work since they were written. What I do know is that what I inferred from the article: that the driver is fairly crashy atm.

In any case this seems like a good opportunity to say this to the developers: Thank you for your efforts so far, and keep 'em coming!:)

[mendieta]

Awesome, makes me even happier that I built and AMD/ATI system. Can't wait.

[Fixxer_Linux]

I can't wait using the open source driver for playing UT2004 (UT3 ?).
:D

[m4rgin4l]

Yey! Now we have an unusable closed source driver and an unusable open source driver...It's so hard to choose.

Anyway, thanks for the update. Slightly good news is better than no news at all.

[Fixxer_Linux]

Yey! Now we have an unusable closed source driver and an unusable open source driver...It's so hard to choose.

Anyway, thanks for the update. Slightly good news is better than no news at all.

fglrx is not so unusable : i can play UT2K4 fine with fglrx 9.3.
I can also play videos / DVD nice (I don't have compiz/fusion). 2D is working well : I have a normal speed everywhere in KDE 3.x while my HD4870 is operating silently.

I've read over the forums the people using open source driver are also rather happy, unless they want to play some 3D games. But that's part of the contract for now : if you go for open source, you can't play.

[m4rgin4l]

fglrx is not so unusable : i can play UT2K4 fine with fglrx 9.3.
I can also play videos / DVD nice (I don't have compiz/fusion). 2D is working well : I have a normal speed everywhere in KDE 3.x while my HD4870 is operating silently.

I've read over the forums the people using open source driver are also rather happy, unless they want to play some 3D games. But that's part of the contract for now : if you go for open source, you can't play.

I'm using Fedora 11, so there's no fglrx for me (unless I go for the unstable rpmfusion repo). Funny enough this is also part of a contract that states that if you buy AMD/ATI you better use a stable distro (I was going to write "an obsolete distro" but that seems to offend some phoronix users). :)

Right now I'm using the ati driver which is only a little bit better than using the vesa driver. The radeonhd also "works" but the system freezes when I switch to a text console.

What I was trying to say with my post is that I don't like news that say "we're now a little bit less bad than before". I appreciate the effort of the developers, but I have to live with a daily reminder that if you want to support the open source initiatives, you have to be willing to pay the price, which in this is case is having to put up with lousy drivers. Don't expect me to be happy about THAT.

[blackiwid]

I thought the 3d part would be more ready.

I planed to buy a hd4870 1gb next week, but as i see i will not have 3d with the open driver till the dx11 ati cards come out (October), fglrx is no option for me. So i have no compiz for several months, I really consider my planed buying now.

Right now i have an x800xl, maybe i look for an used X1950xtx or something like that, is the 3d part for r500 fast enough to play lets say quake wars on 1920x1200 with high settings? (without AA)

[Boerkel]

I'd be happy if i could use Google Earth at least... the open source driver is really nice, but as times passes i realize how often i would appreciate a 3D driver. I won't go back to fglrx, because i can't watch videos there (tearing alarm) and the sleep modes won't work. So i realize that i've wasted some money for my notebook with a good 3d card in it, because i can't use it...
The news that 3d could come by the end of summer saddens me even more... :(

[bulletxt]

I thought the 3d part would be more ready.

I planed to buy a hd4870 1gb next week, but as i see i will not have 3d with the open driver till the dx11 ati cards come out (October), fglrx is no option for me. So i have no compiz for several months, I really consider my planed buying now.

Right now i have an x800xl, maybe i look for an used X1950xtx or something like that, is the 3d part for r500 fast enough to play lets say quake wars on 1920x1200 with high settings? (without AA)

Don't expect a working/stable/efficient ATI 3d driver before 2011. Considering the world ends in 2012 I suggest to avoid buying AMD. Buy an NVIDIA, at least you "finish" with a working gpu (but you might go to hell since their blob driver is unmoral. It's the only real driver really working good on Linux as of today but it's unmoral, so you decide: heaven without candy or hell with candy) :P

[d2kx]

I thought the 3d part would be more ready.

I planed to buy a hd4870 1gb next week, but as i see i will not have 3d with the open driver till the dx11 ati cards come out (October), fglrx is no option for me. So i have no compiz for several months, I really consider my planed buying now.

Right now i have an x800xl, maybe i look for an used X1950xtx or something like that, is the 3d part for r500 fast enough to play lets say quake wars on 1920x1200 with high settings? (without AA)

Why is fglrx no option for you? If it's because it's closed source, then why do you want to buy a high-end card that couldn't be properly accelerated by the opensource driver anyway?

[Kano]

Maybe because you have to switch between drivers to get a tearfree xv?

[blackiwid]

because i use then another os (windows) to play games. all other than games dont need soo much acceleration.

But i want get at least in near future compiz working with it, and enemy territory. maybe with 1920x1200 then i am happy for other games i have to use windows anyway, ok a few of em will work after several time with mesa, but thats no good alternative.

[bridgman]

In case this helps anyone understand the timing and status better, by early April Richard and Cooper had most of the driver code written and running including glxgears, texture operations, and arb_fp/arb_vp support with a working shader assembler. Like most fresh-from-the-developer code, it only really worked on the developers own systems and it had a bunch of obvious bugs, but all the core bits were in place and ready for integration testing.

Unfortunately, by that time it had also become obvious that we would have to move onto the new bufmgr/cs code (from radeon-rewrite) before the driver could be broadly useful, since radeon-rewrite was going to merge into mesa master shortly. In case it's not obvious, that was *not* part of the original plan.

Alex wrote an initial implementation of the new CS ioctls in mesa/drm (that's why the drm code is in ~agd5f/drm), and in early April we started moving the driver across to the new code base. That work is now pretty much finished, although there is at least one open problem with buffer allocation which shows up as a glxgears segfault, and the texture code still needs to be merged with bufmgr/cs and made to work.

If you put your thumb over the April-to-now time period (mostly porting to radeon-rewrite and vacations) you'll probably get a better sense of the rate of progress.

[mendieta]

In case this helps anyone understand the timing and status better[

I does indeed!. So, how are things looking from now on considering the change in plans. Could you please give a bit of a flavor of the next milestones and circa when they are being shot for. Of course I understand you might prefer not to, given that some ... ahem ... systematically negative people could hang on to it in the future to complain if something gets delayed.

I really think it would be nice to have parties in some bigger cities (in whatever country people are) to celebrate THE milestone :DI don;t know how many people would be interested, but I think it will be a historic moment for open/free software (unimaginable just 10 years ago).

Thank you all who are making this happen!

[JeanPaul145]

In case this helps anyone understand the timing and status better, by early April Richard and Cooper had most of the driver code written and running including glxgears, texture operations, and arb_fp/arb_vp support with a working shader assembler. Like most fresh-from-the-developer code, it only really worked on the developers own systems and it had a bunch of obvious bugs, but all the core bits were in place and ready for integration testing.

Unfortunately, by that time it had also become obvious that we would have to move onto the new bufmgr/cs code (from radeon-rewrite) before the driver could be broadly useful, since radeon-rewrite was going to merge into mesa master shortly. In case it's not obvious, that was *not* part of the original plan.

Alex wrote an initial implementation of the new CS ioctls in mesa/drm (that's why the drm code is in ~agd5f/drm), and in early April we started moving the driver across to the new code base. That work is now pretty much finished, although there is at least one open problem with buffer allocation which shows up as a glxgears segfault, and the texture code still needs to be merged with bufmgr/cs and made to work.

If you put your thumb over the April-to-now time period (mostly porting to radeon-rewrite and vacations) you'll probably get a better sense of the rate of progress.

Thank you for the explanation. It answered some of the the questions I had concerning the R600/R700 code (mostly about timing).

[bridgman]

The tasks and milestones are pretty easy but putting dates on them right now is tricky. The big unknown is whether our in-depth understanding of current Mesa internals is solid or not, and we'll only find that out by testing.

The sequence of events for the short term is pretty simple though -- fix whatever is causing the glxgears segfault, finish hooking up texture code to the new buffer management logic, then test, fix, repeat. Most of the code is already written and has at least passed basic smoke tests, so the driver could come up really fast or it could drag on for a while. It all depends on whether we find any fundamental defects in the design. I don't think we will, but you never know.

[MU_Engineer]

Maybe because you have to switch between drivers to get a tearfree xv?

Yes, but you can just use OpenGL output under fglrx if you have an okay R6xx/R7xx GPU and there is far less tearing than with XVideo under fglrx. (My HD 3850 has about 40% GPU load at 300 MHz when playing back 1080i video using OpenGL output.) It's not an ideal situation as OpenGL output in my opinion doesn't look as good as XVideo, but it should be "good enough" for those who also want to use 3D applications with their ATi GPUs.

If somebody is running an HTPC or just wants to do 2D desktop work and play videos, I suggest skipping fglrx and using the Xorg radeon driver with a 2.6.30 or better kernel. XVideo with xorg-video-radeon has *excellent* video quality and is much lighter on the CPU and GPU than fglrx + OpenGL output.

[cruiseoveride]

3D Driver Almost Working

Please reserve that for when this driver can play at least half the games the Nvidia driver can play.

[Kano]

First of all using opengl for video is just a really ugly workaround and no solution - xv has to work correctly! Also fglrx opengl does not work with xinelib backend in kaffeine/xine somehow here.

[Melcar]

Please reserve that for when this driver can play at least half the games the Nvidia driver can play.


I didn't know the nvidia open driver could play 3D games.

[Kano]

noueveau might be able to do, but never tried.

[MostAwesomeDude]

noueveau might be able to do, but never tried.

I am disappoint. http://nouveau.freedesktop.org/wiki/GalliumHowto states, in a nutshell, that nouveau's Gallium code is broken, in heavy development, experimental, and does not accept bug reports.

As far as I know, the most advanced thing that works decently correctly with nouveau is xmoto.

[Louise]

The tasks and milestones are pretty easy but putting dates on them right now is tricky. The big unknown is whether our in-depth understanding of current Mesa internals is solid or not, and we'll only find that out by testing.

The sequence of events for the short term is pretty simple though -- fix whatever is causing the glxgears segfault, finish hooking up texture code to the new buffer management logic, then test, fix, repeat. Most of the code is already written and has at least passed basic smoke tests, so the driver could come up really fast or it could drag on for a while. It all depends on whether we find any fundamental defects in the design. I don't think we will, but you never know.

That sounds like a pretty cool state to be in.

I guess anyone with GDB debugging experience could start hammer on those bugs without knowing anything about graphics?

[torham]

3D is great, but I would settle for some good 2D. Neither the fglrx driver or the radeonhd driver give usable performance in 2D yet. I have little hope for fglrx, even the catalyst driver for Windows is terrible. Try dragging a window around with show contents turned on, it's slower than it was a decade ago!

Still it is nice to hear things are progressing, hopefully I will be able to use my shiny new video card someday. For now, I wonder if we are overselling how well these things work. If anyone is considering buying one of the newer ATI cards for anything besides games, they are crazy.

[d2kx]

3D is great, but I would settle for some good 2D. Neither the fglrx driver or the radeonhd driver give usable performance in 2D yet. I have little hope for fglrx, even the catalyst driver for Windows is terrible. Try dragging a window around with show contents turned on, it's slower than it was a decade ago!

Still it is nice to hear things are progressing, hopefully I will be able to use my shiny new video card someday. For now, I wonder if we are overselling how well these things work. If anyone is considering buying one of the newer ATI cards for anything besides games, they are crazy.

What hard- and software do you use? 2D acceleration should be very fast with the open source stack.

[torham]

What hard- and software do you use? 2D acceleration should be very fast with the open source stack.

It's a 4850, I'm using Debian's packages, tried both the radeon and the radeonhd drivers, with DRI on and both EXA and XAA.

xserver-xorg 1:7.4+3
xserver-xorg-video-radeon 1:6.12.2-2
xserver-xorg-video-radeonhd 1.2.5-1
linux-image-2.6.30-1-686 2.6.30-1

[nanonyme]

It's a 4850, I'm using Debian's packages, tried both the radeon and the radeonhd drivers, with DRI on and both EXA and XAA.

xserver-xorg 1:7.4+3
xserver-xorg-video-radeon 1:6.12.2-2
xserver-xorg-video-radeonhd 1.2.5-1
linux-image-2.6.30-1-686 2.6.30-1Do note that there is no XAA for r6xx/r7xx cards, only EXA.

[bridgman]

3D is great, but I would settle for some good 2D. Neither the fglrx driver or the radeonhd driver give usable performance in 2D yet. I have little hope for fglrx, even the catalyst driver for Windows is terrible. Try dragging a window around with show contents turned on, it's slower than it was a decade ago!

torham, can you please start another thread and pastebin your xorg log, conf and dmesg output ? It sounds as if acceleration isn't enabled on your system for some reason.

As a quick check, see if xvinfo finds textured video adapters.

[agd5f]

That sounds like a pretty cool state to be in.

I guess anyone with GDB debugging experience could start hammer on those bugs without knowing anything about graphics?

Yes, more or less. In addition, there is a programming guide, shader ISA documentation, and register specs available for download:
http://www.x.org/docs/AMD/
So with GDB and specs you can get a general idea of what's going on in the mesa code by just tracing the code. The redbook demos are very simple.

[RoboJ1M]

Sooo, pretty soon I'll have a 100% open source OS, including WiFi.

Coolness. :cool:

On fglrx: Seems to all work fine for me, except maximizing windows with compiz has a 1-2 second lag on it (so I turn compiz off, 'ray)

System:

Phenom II X3 720 BE
Biostar TA790GX AM2+ board
4GiB DD2-533
Integrated Radeon 3300
1440 x 900 monitor
3 x 500GiB HDD
Ubuntu 9.04 32bit.

Don't know why maximizing windows has such bad latency, everything else is pretty sharp.

bridgman: You're the man now, dog!

Regards,

J1M.

[d2kx]

It's a 4850, I'm using Debian's packages, tried both the radeon and the radeonhd drivers, with DRI on and both EXA and XAA.

xserver-xorg 1:7.4+3
xserver-xorg-video-radeon 1:6.12.2-2
xserver-xorg-video-radeonhd 1.2.5-1
linux-image-2.6.30-1-686 2.6.30-1

Debian has removed the firmware out of the Linux kernel since 2.6.30. I assume you are using Debian/sid. Try installing the "firmware-linux" package and reboot.

[JeanPaul145]

Sooo, pretty soon I'll have a 100% open source OS, including WiFi.

Coolness. :cool:

On fglrx: Seems to all work fine for me, except maximizing windows with compiz has a 1-2 second lag on it (so I turn compiz off, 'ray)

System:

Phenom II X3 720 BE
Biostar TA790GX AM2+ board
4GiB DD2-533
Integrated Radeon 3300
1440 x 900 monitor
3 x 500GiB HDD
Ubuntu 9.04 32bit.

Don't know why maximizing windows has such bad latency, everything else is pretty sharp.

bridgman: You're the man now, dog!

Regards,

J1M.

I have a 1-2 second lag with unminimization in gnome, as in: minimize a window, then focus on it again. Maximization and restoring works fine here. Happens only when using compositing (in gnome I use compiz as compositing window manager).

The funny thing is, I also get that lag when using KDE's KWin. when I enable the KWin plugin for performance tracking, a clear spike to the maximum of the scale is noticeable (I assume that cpu usage is being tracked).

It's a damn shame too, because this means that the fault lies with fglrx. I think that if this issue were to be fixed in Catalyst 9.6 that it certainly would make the wait for FOSS radeon(hd) 3D support for the R600/R700 cards a bit less painful.

[bridgman]

The delay resulted from an xserver patch being backed out to fix a corruption issue on Intel HW AFAIK - reapplying the patch seems to make the delay go away. My understanding is that this is an xserver issue not a driver issue; you hear similar complaints from people with different hardware and drivers as well.

[Fran]

My understanding is that this is an xserver issue not a driver issue; you hear similar complaints from people with different hardware and drivers as well.
But then why does it not happen with radeon/radeonhd/intel? The thing that surprised me the most when switching from fglrx to radeon was the great performance with composite. That includes resizing/maximizing (no noticeable lag).

[bridgman]

The reports I have seen indicated a similar delay with the open source driver when running compositing. All the reports saying there was no delay with the open source drivers were on 6xx/7xx where the lack of 3D support prevents the use of GL-based compositing.

I have also seen a number of posts from Intel users discussing the tradeoffs associated with the patch; screen corruption vs delays.

Are you seeing something different, and if so which GPU are you using ?

[legume]

The reports I have seen indicated a similar delay with the open source driver when running compositing

When I had a R500 about a year ago, the maximise delay did not happen with OSS drivers + compiz if EXA was enabled. It did happen with OSS + compiz if XAA was used.

[Melcar]

Using the open drivers in Jaunty with a 200M you can notice a slight delay with Compiz while maximizing/minimizing. Kwin is not that bad, but you can indeed notice some lag when maximizing/minimizing as well. Using xterm with the open drivers is smooth as silk however, whereas with fglrx its simply painful; Metacity takes at least 3 seconds to update, and Kwin bogs down to a crawl.

[d2kx]

@all people experiencing slow Composite performance (like with maximizing/minimizing) with Ubuntu 9.04 (Gnome or KDE):

add this ppa repository to your APT sources and upgrade the Xserver to a fixed one:

Click me, I am of help! (https://launchpad.net/~ubuntu-x-swat/+archive/xserver-no-backfill)

[Fran]

Are you seeing something different, and if so which GPU are you using ?

Ah, ok. I have a HD3850. But I don't experience any delay with my integrated intel (G965).

[Melcar]

@all people experiencing slow Composite performance (like with maximizing/minimizing) with Ubuntu 9.04 (Gnome or KDE):

add this ppa repository to your APT sources and upgrade the Xserver to a fixed one:

Click me, I am of help! (https://launchpad.net/%7Eubuntu-x-swat/+archive/xserver-no-backfill)


Yep, this works. Not only are the Compiz issues resolved, but the CCC no longer that +5 seconds to load.

[JeanPaul145]

Yep, this works. Not only are the Compiz issues resolved, but the CCC no longer that +5 seconds to load.

Indeed, I can confirm that the xserver from the PPA d2kx provided, works.
Running KDE 4.3 RC1 right now with compositing turned on, on a radeon HD4870 card.

@bridgman: I was indeed aware that the direct cause for this performance regression was the removal of a xorg patch. The reason, however, that I said the fault lay with catalyst is that I was (and still am, to be honest) under the impression that nvidia's blob reaches acceptable performance on their cards. If this incorrect, I apologise.

I do wonder, regardless of where the blame lies, about what can be so computationally intensive about unminimizing a window that, when a certain patch is removed from xorg, the performance for that functionality drops to a level where lag is noticeable.
The fact that this happens tells me that the performance for that operation wasn't too high to start with (although this doesn't HAVE to be the case, I guess that would also depend on the invasiveness of the xorg patch in question).
I assume the window has to be rendered again, but with modern gfx cards that shouldn't be an issue; it is what the hardware is built for:D

[bridgman]

I don't know exactly what is happening here either. I have seen similar performance complaints on all hardware, but I have also seen users who don't seem to have the problem. It's a very high-noise situation. My first thought was something simple like "EXA good, XAA bad" but the user reports didn't seem to exactly match that either.

The time-consuming operation appears to be copying either the entire screen or the unminimized window (not sure which) from video memory to system memory without going through an acceleration API. Depending on how the memory manager has set up caching & prefetching on the video memory (via MTRR or PAT), this could either be very fast or very slow. You can't just leave the memory in a "fast" mode because then changes made by the GPU would be missed by the CPU.

Take all of this with a grain of salt though... I haven't traced through the operation myself or spoken directly with someone who has; this is just what I have been able to distill from all the posts and comments.

[Melcar]

I should note however, that with the patch I'm now having problems resuming from suspend.

[alex46]

Hello to everybody

I have changed from fglrx to radeonhd and i it works quit good. Now i have DRI Mesa and Radeonhd working with Software acceleration.
Faster in many situations as the fglrx but is there a possibility to get hardware acceleration to work??? Or in other words is there a posibility to get compiz-fusion to work with radeonhd - dri - mesa ....
I have tried but if there is no r600_dri.so module (My Ati Card:Radeon HD3870) there is no possibility to get hardware accelaration to work.

Thanks for answers.

[agd5f]

Hello to everybody

I have changed from fglrx to radeonhd and i it works quit good. Now i have DRI Mesa and Radeonhd working with Software acceleration.
Faster in many situations as the fglrx but is there a possibility to get hardware acceleration to work??? Or in other words is there a posibility to get compiz-fusion to work with radeonhd - dri - mesa ....
I have tried but if there is no r600_dri.so module (My Ati Card:Radeon HD3870) there is no possibility to get hardware accelaration to work.

Thanks for answers.

Work is underway on an open source 3d driver for r6xx/r7xx cards however, it's not yet far enough along to run compiz. Just basic redbook GL demos right now.

[bridgman]

Hello to everybody

I have changed from fglrx to radeonhd and i it works quit good. Now i have DRI Mesa and Radeonhd working with Software acceleration.
Faster in many situations as the fglrx but is there a possibility to get hardware acceleration to work??? Or in other words is there a posibility to get compiz-fusion to work with radeonhd - dri - mesa ....
I have tried but if there is no r600_dri.so module (My Ati Card:Radeon HD3870) there is no possibility to get hardware accelaration to work.

Thanks for answers.

What you should have right now is hardware EXA (2D) and Xv (video) acceleration but not hardware 3D acceleration. If you don't have EXA and Xv hardware acceleration then you probably need to make sure you have an appropriate drm (kernel graphics) driver.

There's an article link at the front of this thread with a bit more information on 6xx/7xx 3D status.

[alex46]

Thanks for your fast reply

and real thanks for this great working modules.

What time frame is possible for the modules to work with compiz-fusion???

Thanks

[bridgman]

Ask us again in a week. We're just working through blocker bugs and missing bits right now so it's a bit hard to predict a short term schedule.

[tball]

I would love using this driver, If I could get the low power modes to work proberly.
When enabling this in my xorg.conf


Option "ForceLowPowerMode" "True"
Option "DynamicPM" "True"
Option "ClockGating" "True"


I get funny (purble) colors at icons and my icons in the kde-startment is corrupted. It is specially when enabling ForceLowPowerMode i see the corruptions?

Could it be the new clock in the chip is making my gpu too slow to redraw surtain things before it is drawned to the screen?

I need the low power mode, because else my laptop is getting too hot (not that it crash, but I don't like it).

Without the ForceLowPowerMode, the driver works flawless.

Specs:
C2D 2,5 gHz
Radeon mobility HD3650

Thx in advance

[bridgman]

Are you actually using the 6xx-rewrite radeon driver and 6xx-7xx-3d drm branch, or standard radeon X driver and drm ?

ForceLowPowerMode also changes the number of active PCIE lanes; first guess is that the PCIE lane change is more likely to be causing the problem than the clock change.

[tball]

Are you actually using the 6xx-rewrite radeon driver and 6xx-7xx-3d drm branch, or standard radeon X driver and drm ?

ForceLowPowerMode also changes the number of active PCIE lanes; first guess is that the PCIE lane change is more likely to be causing the problem than the clock change.

I am using the 6xx-7xx branch of drm and radeon.
Should i use drm master?

[bridgman]

The 6xx-7xx branch of radeon is obsolete; all the code was merged to master a few months ago. You may find you already are using radeon master; my recollection is that the PM options went in after the 6xx/7xx code was merged in, so I don't *think* you would be getting power management options with the 6xx-7xxx branch of radeon.

For drm, it depends a lot on what distro/kernel you are running and whether you want to try the 6xx/7xx 3D driver code. If you want to run the 3D driver code then you need the r6xx-r7xx-3d branch from agd5f's repo (~agd5f/drm on freedesktop.org) and 2.6.28 or earlier kernel.

If you aren't trying to test the 6xx/7xx 3D code and are running Jaunty then you have the necessary drm code in your kernel already, otherwise you probably want to pick up 2.6.30 or later kernel code.

[tball]

The 6xx-7xx branch of radeon is obsolete; all the code was merged to master a few months ago. You may find you already are using radeon master; my recollection is that the PM options went in after the 6xx/7xx code was merged in, so I don't *think* you would be getting power management options with the 6xx-7xxx branch of radeon.

For drm, it depends a lot on what distro/kernel you are running and whether you want to try the 6xx/7xx 3D driver code. If you want to run the 3D driver code then you need the r6xx-r7xx-3d branch from agd5f's repo (~agd5f/drm on freedesktop.org) and 2.6.28 or earlier kernel.

If you aren't trying to test the 6xx/7xx 3D code and are running Jaunty then you have the necessary drm code in your kernel already, otherwise you probably want to pick up 2.6.30 or later kernel code.

Thx for your reply. I will try radeon master then instead, which I asume is the radeon rewrite. :-) I guess drm hasn't anything related with powermanagement.

I am using Arch btw.

[bridgman]

Hold on thar' ;)

The radeon-rewrite effort was a rewrite of the radeon portion of mesa, nothing to do with the radeon driver. Just to make sure we're talking about the same thing :

- radeon driver is in xorg/driver/xf86-video-ati

- mesa driver is in mesa/mesa

- radeon-rewrite is a branch of mesa/mesa, now merged back into master

[tball]

Hold on thar' ;)


Ok, but shouldn't it be enough upgrading to radeon-git without touching mesa? If my only interest is powersaving?

[bridgman]

Absolutely. The radeon git code should be all you need. I only mentioned mesa in response to your comment about radeon-rewrite (since that was a mesa branch).

[agd5f]

Ok, but shouldn't it be enough upgrading to radeon-git without touching mesa? If my only interest is powersaving?

yes, all the pm stuff is in the ddx at the moment.

[agd5f]

I get funny (purble) colors at icons and my icons in the kde-startment is corrupted. It is specially when enabling ForceLowPowerMode i see the corruptions?

Could it be the new clock in the chip is making my gpu too slow to redraw surtain things before it is drawned to the screen?

I need the low power mode, because else my laptop is getting too hot (not that it crash, but I don't like it).

Without the ForceLowPowerMode, the driver works flawless.


Probably the pcie lanes as Bridgman noted. You could try commenting out the calls to change the pcie lanes in the driver. The corruption is probably due to EXA DFS. DFS is kind of flakey, especially when PCIE lanes are reduced, so you can try disabling DFS (Option "EXANoDownloadFromScreen")

[tball]

Thank you both. I will try and report back.
Great to have direct contact with the devs :-) Thats one of the reasons I love oss.

[Pfanne]

thats what i kinda love about you amd guys!
while neither driver is perfect (and i dont hold it against you + you can see the progress and the work that is being done) you still answer questions and help out with the people and their problems and questions!
big thanks!

[Vash63]

Hmm, similar situation as above, trying to use the git radeon driver to get my fan speed a bit lower, I'm getting a different issue though. The xorg.0.log isn't showing anything too unusual but the screen just turns black as soon as X starts up. The fan then slows down so it seems to be working, but Xorg locks up and I have to ssh in to shut down my PC.

It's an R700 (4870 X2), I'm wondering if something that ForceLowPowerMode is doing is messing with the PLX chip between the GPUs.

[JeanPaul145]

Hmm, similar situation as above, trying to use the git radeon driver to get my fan speed a bit lower, I'm getting a different issue though. The xorg.0.log isn't showing anything too unusual but the screen just turns black as soon as X starts up. The fan then slows down so it seems to be working, but Xorg locks up and I have to ssh in to shut down my PC.

It's an R700 (4870 X2), I'm wondering if something that ForceLowPowerMode is doing is messing with the PLX chip between the GPUs.

I'm thinking that a GPU that's not properly cooled will lock up. And since you've got 2 of them (and both are hotheads ;) ), the high fan speed might be mandatory.

[Vash63]

Nah, it runs fine in Windows at very low speeds, plus the black screen is instant, the second X starts up, which isn't indicative of a heat issue. In Windows the default 2d speed is about 30% fan, in Linux without ForceLowPowerMode it's 100% and sounds like a jet engine.

[RoboJ1M]

Hi,

Apologies for this being off topic but I've got another question about Ubuntu 9.04 and fglrx and I thought I'd ask it while the ATi brains were about.

On my server, which as mentioned uses a 790GX + SB750 chipset, the monitor blanks when not being used but never seems to go into DPMS off (light never flashes, screen still glowing with backlight bleed, comes back on instantly when mouse moves)

Not sure if this is fglrx not playing nice or an Ubuntu setting I can't find.

Also, thanks to the person who posted a ppa fix to the slow maximise problem.

bridgman: A realy OSS radeon driver question, how did unravelling the UVD2 on the 780G go? Can it be made available without compromising the DRM (the bad kind) part? Is it the same UVD2 as on the 790GX?

Regards,

J1M.

[tball]

@bridgman and @agd5f

The Option "EXANoDownloadFromScreen" did actually help. No visible corruptions anymore, but with ForceLowPowerMode turned on the computer freeze when login out, shutting down or suspending. I have to hold down the power button to shut down.

When it isn't enabled everithing works.

So, how much does the ForceLowPowerMode option do more than de other options? Can I leave it disabled?

[agd5f]

Hmm, similar situation as above, trying to use the git radeon driver to get my fan speed a bit lower, I'm getting a different issue though. The xorg.0.log isn't showing anything too unusual but the screen just turns black as soon as X starts up. The fan then slows down so it seems to be working, but Xorg locks up and I have to ssh in to shut down my PC.

It's an R700 (4870 X2), I'm wondering if something that ForceLowPowerMode is doing is messing with the PLX chip between the GPUs.

Not likely that it's messing with the PLX chip. More likely, the clocking changes have to be synchronized between GPUs or something like that.

[agd5f]

@bridgman and @agd5f

The Option "EXANoDownloadFromScreen" did actually help. No visible corruptions anymore, but with ForceLowPowerMode turned on the computer freeze when login out, shutting down or suspending. I have to hold down the power button to shut down.

When it isn't enabled everithing works.

So, how much does the ForceLowPowerMode option do more than de other options? Can I leave it disabled?

You don't have to enable any of the pm options. ForceLowPowerMode runs the card at lower clocks all the time. DynamicPM only lowers the clocks when the displays go to sleep (dpms off). PM is very tricky to get right on all boards. I suspect we may need to change clocks more gradually in limited steps rather than changing the clock completely in one go or some additional delays are needed here and there.

EDIT: as noted by bridgman, the PCIE lane changing code is probably to blame on multi-GPU cards. You could test by removing the calls to set the PCIE lanes in the pm code in radeon_pm.c in the ddx.

[bridgman]

Apologies for this being off topic but I've got another question about Ubuntu 9.04 and fglrx and I thought I'd ask it while the ATi brains were about. On my server, which as mentioned uses a 790GX + SB750 chipset, the monitor blanks when not being used but never seems to go into DPMS off (light never flashes, screen still glowing with backlight bleed, comes back on instantly when mouse moves). Not sure if this is fglrx not playing nice or an Ubuntu setting I can't find.

Geez, if someone posts about the 600/700 3D driver it's going to seem like *they're* off topic ;)

I don't know much about this area at all; please start a new thread in the proprietary driver area.

bridgman: A realy OSS radeon driver question, how did unravelling the UVD2 on the 780G go? Can it be made available without compromising the DRM (the bad kind) part? Is it the same UVD2 as on the 790GX?

Haven't gotten to it yet, still working on things we may need for fininshing 6xx/7xx memory management. 780G and 790GX have the same generation of UVD hardware, an early version of UVD2 IIRC.

[agd5f]

For those of you with x2 cards having problems with ForceLowPowerMode, please try the patch attached to this bug:
http://bugs.freedesktop.org/show_bug.cgi?id=22669

[legume]

Geez, if someone posts about the 600/700 3D driver it's going to seem like *they're* off topic ;)


Getting back on topic :-)

I read redbook hello is working for devs now so decided to try with r6xx-rewrite.

RV670 AGP card
agd5f modules on 2.6.26.5
xf86-video-ati from yesterday
todays mesa git (built with --disable-gallium to avoid a build error)

r6xx-rewrite locks up - SysRq able, no output to dmesg, but some normal looking but I guess truncated debugging output to terminal.

6xx-r7xx-support works (although it loses the image if window moved)

[bridgman]

I was testing last night on an rv620 and comparing notes with the other devs; seems like there are some problems on 6xx which don't happen on rv770 (which is what the devs generally have in their systems). Once the two big issues (timestamp generation for memory buffer aging and making texture code work with the new bufmgr) are knocked off I don't expect the 6xx vs 7xx issues will survive for long.

Did you get any output on the screen ? One thing I found is that I had to move the terminal window used to run the tests away from the top left corner of the screen, or the terminal scroll would over-write whatever the test app displayed.

[legume]

Did you get any output on the screen ? One thing I found is that I had to move the terminal window used to run the tests away from the top left corner of the screen, or the terminal scroll would over-write whatever the test app displayed.

Thanks for the info.

I just tried again with the xterm out of the way, but nothing gets drawn.

The output to the xterm seems the same as last time -

vertex shader
18 lines of 4 hex nums
pixel shader
3 lines of 4 hex nums.

The mouse is still smooth and CPU sounds unloaded (I have a noisy CPU fan with it's own temp sensor so can easily hear when it's loaded), but I can't do anything apart from SysRq.

[bridgman]

OK, at least your hang sounds like my hang, so it shouldn't be too evil to find and fix ;)

I'm going to swap out the rv620 for an rv770 today, repeat the testing and see what happens.

[Pfanne]

witnessing real open source magic :D

[Vash63]

Thanks agd5f, that patch worked for me. I left the bug open for now because I think there might be other power-related issues still, mainly sleep mode related that I'll be testing later.

I'm on Gentoo so I just put that patch into a custom ebuild... when should I expect that to hit the main git repo so that I can go back to the default -9999 ebuild?

Edit: Nice, looking at the bug report it already has. Will this patch likely fix the hang going into sleep mode also?

[agd5f]

Edit: Nice, looking at the bug report it already has. Will this patch likely fix the hang going into sleep mode also?

If the hang is due to DynamicPM, then yes it will fix it.

[Vash63]

Is there an easy way to monitor how many PCI-E lanes are being used? That way once KMS and everything are in and we get more power saving options it'd be interesting to see how it scales (and verify that it's working).

[agd5f]

Is there an easy way to monitor how many PCI-E lanes are being used? That way once KMS and everything are in and we get more power saving options it'd be interesting to see how it scales (and verify that it's working).

The driver can set however many it wants to use. The current code sets the number of lanes to 1 when the displays blank when the DynamicPM option is enabled and 4 when ForceLowPowerMode is enabled. The default is 16. The tricky part will be figuring out how the PCIE lane stuff should work on multi-gpu cards.

[Vash63]

Is there a command I can use to print the currently active number of lanes? Just kinda curious.

[bridgman]

I think agd5f created a patch which would indicate power state (and pcie lane) changes in your xorg log. It's not standard code because it's not considered nice to write an infinite number of lines to the log under normal conditions ;)

[Vash63]

Cool, I'll check the gitweb if it's in there.

[bridgman]

It won't be AFAIK, I think he posted it here. Check the original power management thread from a couple of months ago.

[tball]

@bridgman and agd5f
When disabling the function call to change number of active pcie lanes, within the ForceLowPowerMode function in radeon_pm.c, everything works fine.
I can suspend, reboot, shutdown and there aren't any corruptions whatsoever.

EDIT:
Thats with ForceLowPowerMode enabled btw.

[agd5f]

@bridgman and agd5f
When disabling the function call to change number of active pcie lanes, within the ForceLowPowerMode function in radeon_pm.c, everything works fine.
I can suspend, reboot, shutdown and there aren't any corruptions whatsoever.

EDIT:
Thats with ForceLowPowerMode enabled btw.

Fix already pushed:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=8c03c1fdb5ea35570064946557050c87ca30582a

[agd5f]

Is there a command I can use to print the currently active number of lanes? Just kinda curious.

Add this line:
ErrorF("Setting PCIE lanes to %d\n", lanes);

to RADEONSetPCIELanes() in radeon.pm.c and it will print the number of lanes every time the driver changes it.

[tball]

Fix already pushed:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=8c03c1fdb5ea35570064946557050c87ca30582a

But my system isn't a multigpu system? The fix only seem to relate those with a multigpu card.

[bridgman]

Well, then I guess we all learned something ;)

Seriously, AFAIK the change you made was disabling the PCIE lane change always, while the fix Alex pushed only did it for specific X2 cards (ie the pushed fix shouldn't affect your system since you don't have an X2).

If disabling PCIE lanes makes a difference on your system that means there must be some suspend/resume code mucking with PCIE lanes that we don't know about, and that perhaps having a more general way to disable PCIE lane constriction might be useful.

[tball]

Well, then I guess we all learned something ;)

Seriously, AFAIK the change you made was disabling the PCIE lane change always, while the fix Alex pushed only did it for specific X2 cards (ie the pushed fix shouldn't affect your system since you don't have an X2).

If disabling PCIE lanes makes a difference on your system that means there must be some suspend/resume code mucking with PCIE lanes that we don't know about, and that perhaps having a more general way to disable PCIE lane constriction might be useful.

Just to be clear :-) I didn't try Alex's code, because I saw the code wouldn't affect my card. But disabling the pcie lane change completely, seemed to fix my problem. So I guess, as you say, there is something general which has to be fixed with the pcie lane function call, if we talk suspend, shutdown etc.

[nanonyme]

Newest r6xx-rewrite seems to have funky behaviour with redbook hello (RV670, 2.6.28). :3
Originally:
http://koti.kapsi.fi/nanonyme/public/grey.png
If I increase window size:
http://koti.kapsi.fi/nanonyme/public/blue.png
If I decrease window size:
http://koti.kapsi.fi/nanonyme/public/black.png
In case it isn't obvious to everyone, that last picture is what the demo is supposed to look like. ;)
(at least it no longer locks up when changing window size...)

[bridgman]

For what it's worth, that's roughly what I see with my rv620. When I put in an rv770 things seem to look correct. We're running slightly newer code than you (ie todays changes) but we should be able to sync up again tomorrow.

[Vash63]

I know that full PowerPlay-style power management won't be here for a while, but any chance of simple fan adjustments and temperature readings, so I could manually control it? I don't stress my card much in Linux and I'm thinking it could handle a lower speed pretty safely, but obviously I'd like to watch temps also.

[bridgman]

If you're talking about documentation required for a developer to write the code, I think it's available now (between info we have released and datasheets from the fan/temp chip vendors). If you're talking about someone actually *writing* the code, that'll probably take longer but as the developers say "patches welcome".

The main reason devs haven't touched this yet is that the code should really go in the kernel so it's on the list of "things to be done right after kernel modesetting and all the associated bits stabilize".

[nanonyme]

For what it's worth, that's roughly what I see with my rv620. When I put in an rv770 things seem to look correct.Sounds about right then. I recently diverted from Fedora 11 enough to install a stock X server, libdrm from git master with --enable-experimental-radeon-api and xf86-video-ati from git master so test results should be pretty much coherent now. And that rv770 thing; yeah, I guess everyone's expecting it to work at least as well if not better with rv7xx than rv6xx... I was mostly being thrilled that the lockups left, I suspect it had to do with that CS dump disabling commit but unsure. (while it would make sense, kinda, should test - then again, who does regression testing to find out where a but got fixed?)

[bridgman]

Yeah, it was the CS dump. Figures that the biggest problem we had was in the debugging code ;(

In terms of 6xx vs 7xx, it's really a matter of "what the devs have in their machine right now is probably the only thing that works", and that is usually either an rv770 or an rv730. We're just starting to swap out cards and test it on other GPUs now - I'm checking on a couple of 6xx parts and Alex is checking on RS780.

[legume]

Yeah, it was the CS dump. Figures that the biggest problem we had was in the debugging code ;(


Yea that mesa commit fixed my lockup, and let xterm/dmesg display the error - which is fixed by the latest commit to agd5f drm.

So I now have an almost working hello - I can resize OK, but did get grey once when maximising the window.

I have found a reliable way to crash it (hello is unresponsive, using 100% CPU and display distorted) - just move it around while part of it is off screen. I can pkill it OK.

[fr2000]

Why is fglrx no option for you? If it's because it's closed source, then why do you want to buy a high-end card that couldn't be properly accelerated by the opensource driver anyway?

I use ATI 3850 with openSUSE 11.1 with GNOME 2.26, KDE 4.24, Compiz/Fusion 8.2 and everything works stable. Really have had no problems. And I just installed a AMD 955 Black AM3, DDR3 1333Mhz with a ATI 4890 and it works great!!

I run a lot of 3D Linux games and 2D games...they work great...

I use VirtualBox 3.02 for specific Windows programs I may need...I even play some awesome games in Wine/PlayOnLinux, Windows Games running beautifully in Linux without Windows. Even in a separate session...if they die it returns to Linux first session without issues.

So you may want to think about the distro your using...the Opensource driver may not be ready yet...but ATI has gone a long way in helping Linux get some of the bling it deserves even if using their non-Opensource Driver, instead of Windows only.

But keep up the good work on the testing of the opensource driver....I also have been testing the Opensource driver....mainly it is the speed that there is a problem with...everything works...but extremely slow in 3D compared to AMD's driver, at least under openSUSE 11.1. I have even setup SUSE Enterprise Desktop 11, adding the openSUSE 11.1 Compiz XGL repo for Compiz 7.8 latest and the Wine repo and the packman repo and the openSUSE 11.1 oss/non-oss/update repos just for specific updates and then disable them keeping as much of the SLED 11 base as possible and got all Video acceleration to work and all compiz functions with the AMD's Driver 9.6 on ATI 3200 Embedded motherboards...so I am very happy at the moment....totally stable and everything runs clean. Using the opensource driver everything runs fast and clean, but no compiz, or accelerated video or 3D, so I use the 9.6 ATI driver with specific updates and everything works.

Hope that helps.