What functionality is supported for RV670?

[bitnick]

I think it's quite difficult to fint current information on the status of different features of the different radeon drivers.

Anyhow, I have a new computer which I mean to use mainly for gaming, which of course means Windows. But it would be nice to be able to run Linux on it as well. So I'm wondering whether this is a pointless excercise at the moment or whether it would be worthwile.

My graphics card is a passively cooled HD3870 (RV670?).

For it to be worthwile, to me, the kernel/X/driver would have to support the following:

1) Working 2D graphics. With working I mean useable, snappy, not 100% cpu usage for a second just because a window is resized. VT switching must be stable.
2) Power management. I have a passively cooled card; I want a quiet system and I don't want the card to burn itself out.
3) Support for hardware scaling etc for watching movies.

Is there a combination of software that can cope with this?

[bridgman]

There is a useful wiki page which is kept reasonably up to date :

http://www.x.org/wiki/RadeonFeature

As of today, the open source support for RV670 is just modesetting and shadowfb acceleration. The two acceleration features you are looking for have been largely implemented and we are trying to get through the IP review to release them to the public. We haven't done much with 6xx/7xx power management yet but that will be the next priority after getting 6xx/7xx 3D support released into the wild.

The fglrx driver has all those things today, if you are running a supported OS or are willing to do some tweaking.

[bitnick]

That's a useful feature matrix - it went directly to my bookmarks. :)

Would my card fall under R600 or under RS690 here? (Or neither, perhaps?)

The sad fact remains though that still, what is it, 15 months after AMD's initial "Open Source Initiative", there is still no useable driver for these cards. (Open source that is, fglrx is not useable to me, at least, because of prolems when rebuilding kernels, and because of bugs.) A company with AMD's resources should've been able to have a full-fetured driver out in this time period, if the management really cared.

I just hope people doesn't go and buy these cards believing they are actually useful under Linux today.

[bitnick]

BTW, will power management be part of the kernel mode setting in the future?

That seems like the obvious place to put it to me, and it would be very neat as well, having gfx power management as soon as the kernel has booted. Like cpufreq for the cpu.

[oibaf]

Your RV670 fall under the R600 family. If you have an updated driver from git (i.e. from 16 december or later) you can also see all the features supported using "man radeon" (previuos driver version did not have a good feature section).

[bridgman]

I think you will get conflicting answers re: whether power management will be "part of kernel modesetting" or just "part of the kernel" but there is general consensus that putting power management in the drm (the kernel portion of the graphics stack) will be the best solution.

Since a number of usage scenarios do not include drm today (mostly legacy enterprise distros, but they support a lot of users), I expect there may also be some basic power management implemented in the X driver, but that would presumably be disabled if drm was present.

Bitnick, our open source plan was never for AMD to write the driver themselves but to "kickstart" the development through partnership with Novell/SuSE then support community development of the driver from that point. We also maintain a small team of developers to get around the chicken/egg problem where it's hard to write documentation unless you are writing at least parts of the driver at the same time.

The rate of progress will depend in large part on the extent that community resources are contributing. The fglrx driver is still our primary vehicle for supporting new GPUs at launch, although over time I expect you will see open source support become available a lot closer to launch time.

[mattmatteh]

I just hope people doesn't go and buy these cards believing they are actually useful under Linux today.i dont. i dont think alot of people do either. amd/ati always seem to be behind. :(

[val-gaav]

Bitnick, our open source plan was never for AMD to write the driver themselves but to "kickstart" the development through partnership with Novell/SuSE then support community development of the driver from that point. We also maintain a small team of developers to get around the chicken/egg problem where it's hard to write documentation unless you are writing at least parts of the driver at the same time.

That gives AMD the second possition on both fields. Nvidia leads with their blob being the best blob. Intel leads with it's open source driver being first with new technologies (kms,dri2, gem) and having faster open source support for new cards...

What's left for AMD/ATI is being the only one to provide both blob and open source drivers... though I wonder how successfull that can be in the long run.

You were the first one to provide docs without NDA, and I think we all will remember about it. The question is if that is enough to choose your cards while you guys are second in both driver types.

[mattmatteh]

i prefer the open source drivers. fglrx worked acceptably on the 780g that i had. the video tearing was annoying but tolerable. it didnt crash, at least i dont think so. (gigabyte board usually locked up before it had a chance). if it were not for the buggy sata/ahci and usb i would probably have tried amd again. but why be a beta tester ?

[bitnick]

I don't know, I think it's ok to leave it to "the community" to develop the drivers, with just a few developers in-house to slowly do things the community cannot or will not take on, fix difficult bugs and so on. And it's great to "kick-start" the development the way AMD has done.

But community involvement requires documentation, and let's face it: that's still not there. The first docs (register list) were quite useless; you'd have to already be an AMD developer with a lot of inside knowledge to make any use of them. Later (e.g. apr 08) docs seems to be of higher quality, although I haven't looked very deep. Still: 3D is missing, PowerPlay is missing (or perhaps I have just missed it?) ... as long as useful docs aren't out there, I think it's quite ugly to blame the community for not having drivers ready!

[TechMage89]

@bitnick.
For the r500 line, the 3d docs actually are out, and from what I have read, are of very good quality (I have to admit I've never written a driver, but they do seem to explain things fairly well.) It's only the 3d docs for r600 and r700 that are missing, and hopefully, those should come along with a beginning driver soon.

[bridgman]

But community involvement requires documentation, and let's face it: that's still not there. The first docs (register list) were quite useless; you'd have to already be an AMD developer with a lot of inside knowledge to make any use of them.

The most important part of the first release was the atombios parser and header information; the intention was that the driver be written using AtomBIOS calls, and the documents were there to allow troubleshooting and understanding what the AtomBIOS calls were doing.

Later (e.g. apr 08) docs seems to be of higher quality, although I haven't looked very deep. Still: 3D is missing,

The Apr 08 docs were almost entirely 3D, initially for 5xx then a follow-up set of register specs for 3xx/4xx. We released 3D support for the 3xx-5xx family first so that work on the overall driver stack could proceed while we were digging into 6xx and higher (which had a totally different architecture and a significant learning curve). We have been working on 6xx/7xx 3D engine since May/June and are getting pretty close to an initial release.

PowerPlay is missing (or perhaps I have just missed it?)

Power management for 5xx is mostly covered by the AtomBIOS calls and tables we documented last fall, and a fair amount of work is being done with them now (Alex wrote some initial sample code, yangman extended it on radeonhd, Matthew Garrett (mjg59) is extending it on radeon).

The bigger issue is that most of what you know as PowerPlay is a set of proprietary driver extensions, not hardware information. The open source stack doesn't have a comparable dynamic power management framework today so you can't just "plug in the AMD-specific hardware information". Everyone is thinking we suck because we haven't released documentation on some hypothetical "use less power but run real fast" hardware bits but that's not the way power management works. You need a lot of complex software in the driver stack and that just doesn't exist in the open source tree today AFAIK. There are "easy" features like dynamic clock gating but they are only part of the solution, and I believe dynamic clock gating is already turned on in the open source drivers.

Power management for 6xx and up is next on the list after we get initial 3D engine support out the door, but again a big part of the solution is going to be adding more sophistication to the driver stack. It's not just documentation.

... as long as useful docs aren't out there, I think it's quite ugly to blame the community for not having drivers ready!

You mean it would have been ugly if I had done anything like that, but I said no such thing.

You said that if we cared we would have finished the driver development by now; I responded that there was never a plan for us to do the driver development ourselves in the first place. Acceleration support for 6xx/7xx is waiting for us to release more info, but nearly all of the other things you want to see (OpenGL 2.x, DRI2, RDR, KMS, GEM/TTM, Gallium, XvMC) have sufficient information available today and all are being worked on now in the community. The 6xx/7xx support will plug right into that code, so I think everything should come together at roughly the same time.

We made good progress on using the 6xx/7xx 3d engine during the fall (in an NDA repository open to developers from Novell, Red Hat and some independents), and are getting ready for the first release now.

[bitnick]

Fair enough on the first release issue.

When I say that 3D/power management is still missing I'm talking about the card in question: HD3870 (R6xx).

My old Radeon 9500 Pro (R300) died before I could ge it to work well in X (no 2D acceleration so real sluggy desktop). I got a Radeon X800 (R420) a year or two ago (as a gift), and even with EXA and composite acceleration it's *still* cripplingly slow on the desktop. Resizing this Firefox window is a 1 FPS operation with 100% cpu usage. It's comparable to a Riva TNT card with the nv driver. So something important is clearly still missing here for R420.

(And I'm tired of blindly trying different often contradictive advise on how to fix this with xorg.conf settings or other versions of X/libdrm/radeon - this is another documentation issue, concerning the driver man pages, which IMO should list the packages with which it is known to work well and with what settings.)

There're a lot of other irritating issues as well, but I think these mainly lie in limitations in the X environment, much of which might be solved with GEM/KMS/DRI2.

I'm not expecting a "set this bit and get low power consumption" power management solution.

In chip documentation I'm used to (for Altera FPGA's for example) the manufacturer often explains *features* of the product. That is, if the hardware is manufactured with e.g. power management in mind, then the documentation would explain the manufacturer's ideas in a "power management" section. Then it's up to the customer to make the most of these ideas. And I'm sure the possibilities involve many different parts of the chip, all of which would have to be read up on separately to make the most use of them from a power management perspective. But a few hints in the form of "this is our (AMD's) basic ideas on how to manage power consumption of this hardware" could be expected, I think. (The same is true for other features, of course.)

And, saying "we're getting ready for release" without being able to say even approximately when this is going to happen isn't worth much to me. That means there are unsolved issues that just might not get solved at all, in my ears. I hope that will not be the case here, of course.

All is not bad; that you are here as a representative for AMD is great. But I think you (personally and AMD) will have to live with the legacy of really bad support until there really are working drivers out there in the major distros, for current as well as older cards. And there's a lot of frustration in this; many hours spent trying to get at least tolerable performance out of the cards. And probably not by just me.

Edit:
I must confess that I haven't taken more than a very quick look at any recent documentation. Perhaps what I'm whining about is already in there. I did read the first releases more thouroughly though, but tired when I realized it was just a register list (first release) and then basically more of the same (2nd release?).

[bridgman]

When I say that 3D/power management is still missing I'm talking about the card in question: HD3870 (R6xx).

Ahh, OK.

My old Radeon 9500 Pro (R300) died before I could ge it to work well in X (no 2D acceleration so real sluggy desktop). I got a Radeon X800 (R420) a year or two ago (as a gift), and even with EXA and composite acceleration it's *still* cripplingly slow on the desktop. Resizing this Firefox window is a 1 FPS operation with 100% cpu usage. It's comparable to a Riva TNT card with the nv driver. So something important is clearly still missing here for R420.

And I'm tired of blindly trying different often contradictive advise on how to fix this with xorg.conf settings or other versions of X/libdrm/radeon - this is another documentation issue, concerning the driver man pages, which IMO should list the packages with which it is known to work well and with what settings.)

I just re-installed out-of-box Ubuntu 8.10 on an RV570 (X1950 Pro) and Firefox resizing is really fast - and the 570 is a 12-pipe part compared to your 16-pipe 420. The difference might come from a faster CPU but I doubt it - the CPU usage seems pretty low although I haven't really looked much. For an R420 your best bet might be to install Intrepid on a free partition and see how that works.

It's definitely a pain trying to mix and match all the bits right now, since there are so many changes going on at the same time. That's where the distros come in - they try to assemble combinations which work well together, test them as a set, and make them available to users. In six months the X/DRI stack should settle down a lot, but in the meantime I would think hard about running two systems; one with a stable stack for everyday use, and another using newer components for testing so you can contribute to the overall development effort. Not sure I would try to do real work on a bleeding-edge graphics stack right now ;)

I'm not expecting a "set this bit and get low power consumption" power management solution. In chip documentation I'm used to (for Altera FPGA's for example) the manufacturer often explains *features* of the product. That is, if the hardware is manufactured with e.g. power management in mind, then the documentation would explain the manufacturer's ideas in a "power management" section. Then it's up to the customer to make the most of these ideas. And I'm sure the possibilities involve many different parts of the chip, all of which would have to be read up on separately to make the most use of them from a power management perspective. But a few hints in the form of "this is our (AMD's) basic ideas on how to manage power consumption of this hardware" could be expected, I think. (The same is true for other features, of course.)

I guess the point I'm trying to make is that the "missing link" here is not some AMD-specific power management philosophy, it's a generic one and the same for all the GPUs. You have to aggressively clock down the GPU to save power when the workload is low, and you have to clock it back up to get decent performance and reliable operation when the system gets busy or when anything else changes in the system.

Memory clocks affect power but they need to be dynamically tweaked depending on screen resolution, bit depth, number of monitors, tiling mode, and the different drawing blocks which happen to be active at that instant. The power management logic needs to have all this information available to it in real time, and in the current X stack that is just not the case. Power management will need to go into the drm (to get engine info) and be built over KMS (to get display info) if you want to see anything like the power savings we obtain today in the proprietary drivers. We have these discussions on a regular basis with the developers.

And, saying "we're getting ready for release" without being able to say even approximately when this is going to happen isn't worth much to me. That means there are unsolved issues that just might not get solved at all, in my ears. I hope that will not be the case here, of course.

Still aiming to get something out in the Christmas 08 timeframe, although vacations are starting to get in the way. We don't have enough review coverage on the register spec portion so that's definitely going to slip into the new year but we're still trying to get working code and headers in December. I would love to be more precise but unfortunately IP review isn't like development where you have an option of shipping with open issues.

Edit: I must confess that I haven't taken more than a very quick look at any recent documentation. Perhaps what I'm whining about is already in there. I did read the first releases more thouroughly though, but tired when I realized it was just a register list (first release) and then basically more of the same (2nd release?).

If you`re talking about the display registers I agree, those were just register specs intended to be used along with the AtomBIOS parser, headers and tables.

The primary April 08 doc (5xx acceleration) has about 130 pages of "how to program it" documentation plus the register specs.

The first R6xx 3D doc (the instruction set guide published in June) is over 300 pages about how to program the stream processors in the shader core. We put it out early because the new 3D engine is so much more complex than the previous one and I suspect that very few developers have been able to get their heads around it yet. The parts are getting so complex that documentation is becoming less useful (there`s just too much to understand all at once) and our focus is shifting more to providing working sample code along with register specs and some overview docs.

On the power management side (for 5xx) Alex had sample code out a few months ago and the community is running with it. We`re taking the same approach in other cases, eg the tear-free video work which Alex sampled and then other developers extended and merged into the driver tree.

Bottom line is that there is probably more information out there than you realize. It took maybe 6 months (from Dec 07) to get the 5xx 3D engine documented and being used, and the new 3D engine will probably end up more like 8 months (from June 08), which makes sense given the extra complexity and the totally new architecture. Take a look through the 5xx acceleration guide if you want to get a good overview of how the chips work in general, and look through the r600isa doc if you want to see what we`re all dealing with on the 6xx and newer chips. Warning, the r600isa doc may cause your head to explode ;)

[bitnick]

This is the result with Ubuntu-8.10 Desktop (amd64) on my R420:

http://www.student.nada.kth.se/~d97-abr/radeon_ubuntu_bug_081231.jpg

It did actually display an image at first, but with some low, non-native resolution. In Preferences->Screen Resolution I had to deactivate "mirror screens" to be able to select the correct resolution. I was then told to log out and in again, which resulted in the above.

:(

[bugmenot]

Did you already report that bug?

[bitnick]

I have not reported it at freedesktop/xorg bugzilla, no. Would someone look at it if I did? :) Is it enough to attach the information I have written here?

BTW, this is the result with Fedora 10 (i686) after the same procedure (it's a small unscaled crop of the screen; it all look like this):
http://www.student.nada.kth.se/~d97-abr/radeonbug_fedora10_dsc_1531_800.jpg

If I disconnect my secondary monitor it seems to work as it should though, on both Ubuntu-8.10 and Fedora 10.

I just re-installed out-of-box Ubuntu 8.10 on an RV570 (X1950 Pro) and Firefox resizing is really fast

Course it is; I noticed on ubuntu the window contents is not scaled until the mouse button is released. Try Fedora 10 on www.dn.se (a big Swedish newspaper), for example.

[TechMage89]

I don't have any performance troubles resizing firefox with that site (and yes, it does show the contents while resizing, unlike Ubuntu.) There is still some lag redrawing the contents, but that, I'm afraid, is an unavoidable consequence of the Xserver design and exists with all hardware and all drivers.

I'm running Arch Linux and have an x1600.