Should RadeonHD start implementing gallium?

[d2kx]

I've set up a new, clean Debian/sid x86_64 system to due having some kernel problems with the other one. I benchmarked the open source drivers again, this time even with RadeonHD-ShadowFB. The results:


(Click image for PTS global with my system specifications)

Note: While RadeonHD-ShadowFB had a small lead, I can say that in real time it is a *bit* slower than radeon-EXA and in some situations it's even worse, not that anybody thinks that RadeonHD-ShadowFB is the best solution yet.

- d2kx

[TechMage89]

EXA on radeonhd still lacks composting support, which accounts for its poor performance. This really needs to be ported over from the radeon driver, along with texturedvideo.

[bridgman]

Ask and ye shall receive. Look in agd5f's personal radeonhd repository, under the "quick and dirty accel port" branch (head). Full EXA (including compositing), TexVid and XAA all running cp over drm.

[sundown]

Ask and ye shall receive. Look in agd5f's personal radeonhd repository..

We want Master

[givemesugarr]

radeonhd should first finish at least 50% of the 3d support before going with gallium, but if gallium would help fixing it maybe it would be better to start focusing on it and leave the 3d devels witouth gallium for the old radeon branch.
the problem is gallium api stability that i don't remember to have seen frozen.

[bridgman]

One more reminder that the 3d code is not in the X driver (radeon or radeonhd), it's in two other components -- mesa and drm. Saying "do this with radeon and that with radeonhd" doesn't really make sense.

[Vighy]

One more reminder that the 3d code is not in the X driver (radeon or radeonhd), it's in two other components -- mesa and drm. Saying "do this with radeon and that with radeonhd" doesn't really make sense.

What the last paragraph means, in relation to what you say?

http://www.botchco.com/agd5f/?p=28

I'm getting confused... I always thought exactly what you said!!!

[bridgman]

The distinction here is "3d API" (ie OpenGL) vs. "3d engine" (part of the chip). Alex's last paragraph is just saying that the 2d acceleration code in radeon/radeonhd generates commands for the 3d engine directly; it does not call into the mesa (3d) driver to drive the 3d engine.

- 2d acceleration API (XAA, EXA) is in ddx, uses both 2d and 3d engine
- video acceleration API (Xv) is in ddx, uses 3d engine
- 3d acceleration API (OpenGL) is in mesa, uses 3d engine
- drm allows ddx and mesa to share the engines

The R5xx and RS6xx IGP parts were the last to have a 2d engine, so 2d acceleration for the 6xx and 7xx will only use the 3d engine.

Now, if you want to get *really* confused, ask about Glucose

[Tillin9]

So how goes the OpenGL progress, in general? I know a lot of effort is going to getting basic 3d on newer generation chips, which is a worthwhile effort, but usually the way things are phrased, it assumes r300 and lower 3d is good. While in my experience its better than with fglrx on those parts (<r400 seems to not be supported), its far from feature complete or performance optimized. Hence I think a good deal of effort should be spent on improving 3d support on older cards. Since much of the 3d driver is shared, I think that eventually these two goals do overlap, however.

As gallium seems to be way things are headed, I think the sooner the 3d code moved over, the better. Gallium also (please correct me if I'm wrong) makes code reuse a big priority, so improvements are likely to pop up up and down the radeon product line once the initial switch is made, right?

I know I'd love OpenGL 2.x support, non-slow caveated glBitmap and other common functions, and maybe even some 2x AA / AF on my r300.

Any clue Bridgman on how long we have to wait?

[bridgman]

Right now the devs are spending nearly all of their time figuring out how to program the chips, so it's sort of "8 hours of work for 2 lines of code". All that code and knowledge should move across to Gallium pretty easily -- the priority right now is making sure that the devs have to deal with as few *other* problems at the same time so right now we believe we can still make more progress with the older, stable driver model.

Code re-use right now isn't much different between Gallium and the legacy driver model. I don't know exact numbers for radeon parts, but here are some rough ones :

- mesa total code size 1.1 million lines (this will only get bigger with Gallium )

- pre-Gallium driver size maybe 20,000 lines, but only a few thousand get changed going from one CPU to the next

- Gallium driver size maybe 10,000 lines, with probably the same number of lines being changed from one GPU to the next

The main thing to understand is that it's not like Gallium is sitting there with all these new features ready to go, calling "use me, use me !!". The (much larger) code outside the driver is still very much a work in progress and even the APIs are still changing. Everyone agrees that the Gallium model is good enough that "we're gonna do all the new features using Gallium", but that does not mean that all the new features are already *done*.

The first pre-requisite for Gallium is a memory manager, which is also needed for kernel modesetting and DRI2. My guess is that in a month or two we will have enough running 6xx and 7xx 3d code that some devs can start working on Gallium in parallel with learning the rest of the 6xx/7xx 3d engine tricks.