Should RadeonHD start implementing gallium?

[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

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=xor...k_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"

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

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