What functionality is supported for RV670?

[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:



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):


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.