Should RadeonHD start implementing gallium?

[some-guy]

Do you think radeon should work on getting DRI enabled, while radeonHD implements TTM/GEM and DRI2, so that they are *actually* doing different things?

EDIT: As bridgman pointed out, they share mesa/dri so what happens in one happens with the other.

[some-guy]

I think they should because this would allow users to have DRI quicky (via radeon), then have full gallium shortly after that(via radeonhd), also this would allow using http://www.bitblit.org/gsoc/g3dvl/index.shtml for initial xmvc decoding :)

[bridgman]

Um... hold on !! :D

There is only one 3d stack and one pool of 3d developers. The radeonhd 3d stack is the same as the radeon 3d stack. It's not like there are two groups independently developing the same 3d support.

We can split up developers and move more slowly on more things, but I would rather see 6xx 3d supported before that happens since it's going to take a fair amount of work. The recent addition to radeonhd is "dri support", ie the ability to interact with the drm and mesa 3d drivers, *not* the actual 3d code -- 3d drivers are in different projects :

*** ddx aka X driver (modesetting, 2D, video) :

radeon : http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=summary
radeonhd : http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=summary

*** DRM driver, (kernel component, required for 3d, optional for 2d) :

http://gitweb.freedesktop.org/?p=mesa/drm.git;a=summary

*** 3D driver (OpenGL) :

http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=summary

[some-guy]

So the only difference between them is DDX?
I thought they only shared DRI, but if they also share DRM, then there is going to be a long argument about which one to use...

Why did radeon even add r500+ support anyway?

[d2kx]

Well, the reason is, that radeon driver is serious business, as you can see here (I did these benchmarks some minutes ago with gtkperf -c 100):

http://www.phoronix.net/phoronix-test-suite/remote-graph/graph-remote.php?g=BAR_GRAPH&t=GtkPerf&s=Total%20Time&n=0.40&u=Seconds&i=radeon-6.9.0rc1-xaa;radeon-6.9.0rc1-exa;radeonhd-git-xaa;radeonhd-git-exa;fglrx-8.5-xaa;&v=22.00;7.00;26.00;66.00;27.00;&p=LIB&x=1.0.0

radeon has new features more quickly, because it uses AtomBIOS, while the RadeonHD developers write everything by themself.

Btw.: I am wondering if there will be EXA support for fglrx in the future... radeon+EXA just rocks :D

(Radeon X1900 XT 512 / R580)

[some-guy]

Btw.: I am wondering if there will be EXA support for fglrx in the future... radeon+EXA just rocks :D

(Radeon X1900 XT 512 / R580)
AFAIK, it already exists

[bridgman]

I'm guessing that's what the textured2d and texturedxrender options are about but I don't know that for sure. I guess it could still be XAA but using the 3d engine more, not sure.

Anyways, I think those options are still work-in-progress right now but there's no intention to leave them that way.

[bridgman]

d2kx, if you want some fun you could try agd5f's personal "quick and dirty acceleration port" radeonhd branch in git. That's an initial port of fresh radeon acceleration code into radeonhd, prior to merging in some of the accel changes already done in rhd. Run it with drm for best results.

Only EXA is enabled so far, I imagine XAA falls back to shadowfb.

[d2kx]

Textured2D is for R600. It is for good 2D performance using their 3D engines. It is stable and enabled by default on them. I don't think it has anything to do with EXA.
TexturedXrender is nothing but broken.

Didn't know about that branch of agd5f, I might give it a try soon, thanks for the notice...

[bridgman]

TexturedXrender is nothing but broken.


Sure, but it could be broken EXA :D

I mentioned agd5f's branch because it is also being tested over on the #radeonhd IRC channel with some different tests. We had planned to let him finish coding first (XAA and textured video etc..), but what can you do ?

I knew we used the 3d engine on 6xx, but didn't know that was tied to the Textured2D option. Makes sense now, thanks.

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

http://www.phoronix.net/phoronix-test-suite/remote-graph/graph-remote.php?g=BAR_GRAPH&t=GtkPerf&s=Total%20Time&n=0.40&u=Seconds&i=radeon6.9.0rc1-xaa;radeon6.9.0rc1-exa;radeonhd1.2.1-xaa;radeonhd1.2.1-exa;radeonhd1.2.1-shadowfb;&v=15.90;6.81;19.63;52.23;6.68;&p=LIB&x=1.0.0 (http://global.phoronix-test-suite.com/?k=profile&u=d2kx-9149-14590-20241)
(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 :D

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

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

[duby229]

Hi bridgman,

Along a related line, I was just curious about how DRI relates to Mesa, DRM, and the DDX driver? The way I understand it is that DRI is more like an Ideology then an actual project? A set of general guidelines so that DRM, MESA, and the driver can all work together? Am I understanding this correctly?

[glisse]

Hi bridgman,

Along a related line, I was just curious about how DRI relates to Mesa, DRM, and the DDX driver? The way I understand it is that DRI is more like an Ideology then an actual project? A set of general guidelines so that DRM, MESA, and the driver can all work together? Am I understanding this correctly?

DRI is a protocol so that mesa can talk with X server, DRM is in the loop too. DRI2 will move this to have only a communication btw the 3d driver mesa or gallium and the X server. Basicly DRI is mostly about telling mesa where is the rendering windows and what kind of buffer the X program ask for (color depth, zbuffer depth, stencil, ...). So DRI is kind of a language talked by mesa, drm, ddx, xserver

[bridgman]

What he said :D

I'm not totally sure of the history, but my understanding is that "in the beginning" there was just X and Mesa, where Mesa was primarily a software implementation.

The DRI initiative added DRM, the protocols glisse described, and some code in both X and Mesa.

Where it gets confusing is when people talk about "DRI driver" or "DRI support". Sometimes Mesa is called the DRI driver because that's what a direct rendering app mostly talks to. It's probably more correct to say that DRM is "the DRI driver" since it was the piece which (AFAIK) was added by the DRI initiative. You also need "DRI support" in the X driver in order to be able to talk to the other bits (eg initialize DRM etc..) -- that's what was recently added to radeonhd, for example.

The other "hard to understand" thing is how the presence of Mesa and DRM affect the X driver's acceleration code. When you are only using the X driver, the accel code in the X driver can bang on hardware directly or can go through the DRM if available. When you are running 3D as well (via Mesa) the 2D accel in the X driver *has* to go through DRM otherwise Mesa and the 2D accel code both hit the chip directly and interfere with each other badly.

The current radeonhd accel code only uses direct access to the chip registers - that's why you can't run 2D and 3D acceleration at the same time. Agd5f's port of fresh radeon accel code (in the quick & dirty 2d branch of radeonhd; give it a try) adds the DRM paths for 2D acceleration so that 2D and 3D can co-exist by both using DRM. It also adds full EXA and textured video acceleration, which is nice, and which gives us a solid foundation for 6xx/7xx acceleration work.

The radeonhd branch with most recent accel code is here : http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=shortlog;h=quick_and_dirty_2d . It has Alex's fresh port of the latest radeon accel code, plus some "make it fit more cleanly with radeonhd" work by Egbert, plus some of Jerome's work on lockup avoidance and resetting.

[duby229]

OK, I'm following you I think. After reading a half dozen reviews on 4870, and even the 4850, I'm thinking about getting one., but I'm never going to use the fglrx driver, and was wondering how much of the R6xx documentation will be applicable to the RV7xx hardware? I'm just wondering if the two architectures are similar enough that the R6xx doc drop will be sufficient to begin work on RV7xx acceleration?

[bridgman]

I don't know how well it will work, but we're going to try to do 6xx and rv770 more-or-less together, ie as soon as we have something working on 6xx we'll try to get the same code working on rv770. If we get stuck on something with 6xx we may find that we can get it working on 770 and bring the knowledge back to 6xx.

The rv770 has a lot of significant hardware changes but the programming model doesn't change that much. At first glance the transition from 6xx to 770 seems comparable to the jump from 4xx to 5xx, ie the big blocks don't change much but there are a lot of small changes. We made a decision recently not to use any 6xx capabilities which were not also available on rv770.

[Tillin9]

Thanks for keeping us posted. It seems the next couple of months is going to be very interesting. I (like most people, I think) had believed Gallium was a little further ahead than you seem to suggest. I guess I'll just have to try to be a little more patient. :)

[bridgman]

Yeah, these are exciting times for Linux graphics, no question.

I think one contributor to the confusion is that AFAIK "Gallium" just refers to the new driver API, not the features which can now be accelerated using the Gallium API. Gallium itself seems to be doing very well and is probably making progress just like you thought it was.

Unfortunately you may *think* you want "Gallium" but what you really want is "the cool stuff that's gonna be built on Gallium in the future" :D

[TechMage89]

So is my understanding correct that r600/r700 stuff is sufficiently different from previous systems that starting directly on gallium makes sense? Is this what's going to happen in the coming months? Has anyone thought of advanced memory-management stuff yet? I get the impression that gem sidesteps concerns about the over-complexity of the ttm system, so is that what future drm will be based on?

[bridgman]

Dave Airlie (aka airlied) is working on memory management now; his priority is enabling kernel modesetting, but memory management is also a pre-requisite for DRI2 and Gallium. I expect we should have the "classic Mesa" drivers running and developers up to speed about the time that the Gallium pre-requisites are in place, so hopefully it will all come together nice.

600/700 are pretty different on the 2d side because there is no 2d engine, but programming on the 3d side is "less different". Main change is that you can only feed indexes into the 3d pipe (and then the vertex shader fetches the actual vertex data) but the current Mesa implementation for R3xx-5xx seems to be designed around feeding indexes into the engine anyways. I think 6xx mesa is going to be similar to 5xx; looks simple at first but all the shader opcodes are different -- again.

MostAwesomeDude is not gonna be happy, but most of the pain will be confined to a single source file ;)

It's really the lower level stuff (memory management, interrupts etc..) where the 6xx is really different. The 6xx also has 2d emulation in microcode but since 7xx is out now we are not going to use the 2d emulation -- by doing all the 2d acceleration with the 3d engine the same code can pretty much run on 6xx and 7xx.

re: TTM vs GEM, I don't know the exact issues but GEM in its current form seems to be a bit of a better fit for integrated graphics than discrete graphics so I think the final solution will be a bit of both.

[Pickup]

re: TTM vs GEM, I don't know the exact issues but GEM in its current form seems to be a bit of a better fit for integrated graphics than discrete graphics so I think the final solution will be a bit of both.

:confused: A bit of both? does it mean the radeon/radeonhd drivers will use two memory managers or another one will be developed for ATI cards by mixing the best of the two?

Then, the status of the graphix memory management will by this:
- Intel: GEM
- Nouveau: TTM
- ATI/RadeonHD: BOB (Bit Of Both) :eek:.

[bridgman]

As I understand it the plan is to have a "standard" set of API calls (based on GEM) which are sufficient to support common functions like DRI2, then allow the remaining API calls to be implemented in a way which works best for the target hardware (this is where TTM comes in).

If I'm understanding all this correctly (which is far from a sure thing ;)) then what would happen is :

- Intel: GEM for both public and private functions
- Nouveau: Modify public functions to be GEM, private functions stay TTM-ish (or DRI2 could keep supporting TTM paths)
- ATI/AMD: Public functions GEM, private functions TTM-ish

Note that this is just a distillation of IRC and ml comments and I may have it all wrong, but I expect in a month it will all be more clear anyways.

There is ongoing discussion in the mailing lists and IRC channels but most of the meaty stuff happened a couple of weeks ago. The dri-devel ml and IRC are the main hotspots although the focus there has now switched to kernel modesetting (which needs memory management as a pre-requisite). I think Dave is trying to push both ahead at the same time to make sure that KMS's demands on MM are identified before MM gets finished (always a good thing).

There seems to be pretty good agreement on the high-level functionality the MM needs to provide; the reason for going in slightly different directions is that every HW platform seems to need a bunch of different parameters to the calls so the API wasn't locking down fast enough for anyone. By splitting the API into "common" and "hw-specific" sections that seemed to break the logjam.

Presumably some kind of unified "TTGem" API will fall out of this a year from now which works for everyone; the important thing is that today all the devs seem to feel they are able to proceed, and there seems to be agreement on enough common stuff to support other important initiatives like DRI2.

[TechMage89]

So basically gem + a subset of ttm, so more advanced functionality is enabled without making the drm a beast to work with?

[bridgman]

Pretty much. I think the details are still being worked out. Since Dave is also the drm maintainer so it all makes sense ;)

[TechMage89]

Can't wait until the MM stuff is solved, that seems to be the real bottleneck for more advanced drivers (and something far too out of my understanding for me to make any useful contributions besides testing stuff when it comes out.)

[bridgman]

Yep. I have a slide I use internally showing all the initiatives organized by dependency and memory management is over at the left with everything else depending on it.