AMD Releases Additional R600 GPU Programming Documentation

[Ze..]

2d acceleration on R6xx parts and 3d acceleration on 5xx/6xx parts are next on the documentation list.

Excellent.

It'll be good to see how this evolves. I'm actually quite interested in seeing how it all happens. When I get more time I think I'll start contributing to the driver (even though ewwww plain old c )

[bridgman]

Bridgman, one question though. I've taken a look at the 2d acceleration bits in the radeon driver, and although XAA does work on my x1600, the code looks incomplete and hacky, and EXA isn't functional (at reasonable speeds) at all. Large parts of XAA aren't accelerated, or only partially so. I'm wondering if there is some original 2d engine documentation I can refer to, because I don't think the radeon driver is using all of the card's functionality.

As for EXA, I'm not sure what's causing the issue, I need to try some performance profiling.

The manual that came with the R200 info seemed pretty good and gives a pretty good intro to programming the parts. I'm going to try to re-release that some time soon. I was flipping through it over the weekend (while ice fishing ) trying to figure out how much work it would take to bring it up to date for 5xx if not 6xx.

re: EXA, there seems to be some agreement that EXA may need better memory management to work well. I'm not 100% sure of that but it does seem likely.

re: XAA, I have been told by a couple of devs that a lot of the benefit comes from accelerating just a few functions. At XDS there was some talk about mismatches between the current 2d acceleration APIs and the functions which are actually used heavily -- I think the comment was "XAA accelerates all the stuff that nobody uses any more".

[Svartalf]

What do you mean looks incomplete and hacky?

Yow... Guess you told him Dave. Good to see you around here- *I* don't think the work's hacky or kludgy.

[Svartalf]

When I get more time I think I'll start contributing to the driver (even though ewwww plain old c )

What's wrong with a bit of "C" coding? C++ is nice, but it's got some small issues in it's use with drivers. To be sure, it's not as bad as some make it out to be, but it's easier in some ways to do very, very brain-dead things in C++ when you're talking about code for the driver space on an OS- which is a part of why the Linux kernel crowd vehemently oppose the use thereof.

As it stands, I've got a couple of things to get off my plate before I can consider doing some stuff- but it's on my shorter list of things to do.

[TechMage89]

Ok, ok, maybe the language I used was a little too strong, especially given the fact I don't have a lot of experience with C, but when I see lots of comments like "we can't fully accelerate this operation" or "someone needs to find a better way to do this" I do begin to suspect that the code needs some work. (those are rough quotes, I haven't got the code in front of me)

Granted, maybe the operations aren't that important, so no one thought them worth the effort to fix, but I'm afraid I'm a bit of a perfectionist .

Also, I'm not entirely sure what's a silicon problem and what's a coding problem (mainly because I haven't got the docs.)

I'm an object-oriented programmer by training, so when I try to understand a large amount of code, I try to compartmentalize things, but that doesn't seem to work too well on the radeon driver.

Maybe I've bitten off a bit more than I can chew and should just go back to application programming .

At any rate, I regarding EXA, I don't just mean that the performance isn't that good on my card, I mean it's unusable.

[agd5f]

The radeon ddx was written with documentation or directly from ati code drops. Really the only things that were reverse engineered were the XPRESS (RS480) chips and that was more trial and error than reverse engineering. The 3D (mesa) code is another matter. r100 and r200 were written with documentation, r300 (covers r400 as well) was reverse engineered.

The 2D accel code is solid. XAA exposes just about every feature of the 2D engine (fills, blits, image transfers, lines, color expansion, etc.), however, no modern toolkit really uses 2D feature other than fills and blits. As such the only EXA hooks that use the 2D engine are fills, blits, and image transfers. The EXA composite hooks require the 3D engine, so it is a lot more work to get running. We have full support for r100/r200 (in fact it was the HW we used for EXA development since these chips had the best documentation available).

[TechMage89]

My bad, it looks like most of the non-accelerating stuff is trivial. And hardware limited

Another thought: if the 2d engine is no longer included in the r600, does using the 3d engine for 2d acceleration reduce performance over older cards? Would 2d performance be better? If so, could the same method also be used for older cards that don't require it (eg. R500)?

[agd5f]

My bad, it looks like most of the non-accelerating stuff is trivial. And hardware limited

Another thought: if the 2d engine is no longer included in the r600, does using the 3d engine for 2d acceleration reduce performance over older cards? Would 2d performance be better? If so, could the same method also be used for older cards that don't require it (eg. R500)?

You could use the 3D engine for blits, etc. on any of the older cards, it's just a lot more complicated to program. There's a slight bit more overhead using the 3D engine as more state programming is involved, but it's probably pretty negligible in practice. Plus with modern composited desktops you want to use transforms and blends anyway which are not available on the 2D engine. Those come for free (more or less) when using 3D.

[bridgman]

In general the 3d engine is faster these days. That wasn't always the case a few generations ago.

[chrisr]

There are far simpler programs than Compiz that have trouble with the Mesa R300 driver. Try the "rubik" hack from xscreensaver, for example...

And I'm not sure if this message is trying to warn me of a driver bug or a hardware limitation either:

File r300_texstate.c function r300SetTexImages line 301
DXT 3/5 suffers from multitexturing problems!

Has any of the new documentation allowed for the R300 driver to be enhanced further without reverse engineering?