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 :p)
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".
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. :D
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 :p.
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 :p.
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.
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).
My bad, it looks like most of the non-accelerating stuff is trivial. And hardware limited :o
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)?
In general the 3d engine is faster these days. That wasn't always the case a few generations ago.
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:Has any of the new documentation allowed for the R300 driver to be enhanced further without reverse engineering?Quote:
File r300_texstate.c function r300SetTexImages line 301
DXT 3/5 suffers from multitexturing problems!