Radeon Driver To Support ATI R500/600

[bridgman]

So does this mean that some 3d engine specs might be available before the end of the year? I hope so.

With emphasis on the "might", yes. I need to keep stressing that the official schedule is 1Q08

I am willing to help in any way I can, but my understanding of the functioning of graphics hardware is extremely limited (I keep running into new acronyms I need to look up like TTM, LVDS, GART, etc). I can code though, so if there is any way to learn about this and contribute to driver development, I'd like to do it.

You just have to keep asking questions and after a while the new acronyms only take a minute to understand instead of the whole evening. I don't think there's any substitute for sitting down and tinkering -- download the source, make a change (move the frame buffer 32pixels to the right or something), rebuild, and see what happens. Repeat until 5AM. That's how everyone else gets started. Use an old desktop PC and CRT monitor at first, just in case

[glisse]

My understanding is that we need both -- some apps (I'm told) require XAA, while everyone agrees that EXA is the superior approach but needs more work (and probably integration with TTM) before it's really going to shine.

My non-technical impression is that "everyone agrees EXA is far superior even though all the available EXA implementations seem to be dog-slow"

I think we're all on the same page here. We need to get the bottom level infrastructure (DRM etc..) in place anyways, not spend much time on XAA, and do everything we can to help EXA evolve and improve to the point where it works for everyone.



Yep. We're going to need pretty much the same processing whether the final representation is blitted into a window or whether we use overlay, and all that processing is going to need DRM + memory management + 3d processing. The only interesting point is that we don't necessarily need the full GL stack for simple video processing so in principle the work could happen in parallel with creating a final GL driver.

Either way, we're going to get the info out there, see what happens, and help where we can.

My own feeling is that the true future acceleration architecture is opengl which the X server can use trough glucose. I hope i will be able to demonstrate this at fosdem with ttm gallium driver for radeon hw.

I don't say that this will be faster that directly banging the card with specifics bits for each operations (this way is definitly the faster one) but the development and support will be a lot easier with only doing a gl driver. It's just that i believe you can get more than acceptable performance this way.

[TechMage89]

I understand that basic 2d operations (eg XAA style acceleration) are consistant up through the r500 line of cards. Is there a place I can find this stuff documented, or do I have to sift through the Radeon driver to figure it out? I would like to see (when I have some time to work on it) if I can get some kind of XAA acceleration working with the RadeonHD driver. Yeah, I know it's kind of backwards, but right now, I feel it's the only thing I have a hope of understanding.

[bridgman]

You have to sift through the Radeon driver today, but I'm trying to get the original R200-era documentation package re-released without NDA -- that provides some pretty good information about how to use the 2d accelerator. We also need to release some more register info to cover differences in the later chips. The acceleration itself doesn't seem much different, but the accelerator needs to know about a bunch of memory management things which *are* different on the later chips.

Looking at the 2d code seems like a pretty good place to start. I am told there are two sets of code paths -- one which accesses registers directly and another which uses commands passed through the ring buffer (the chip supports both modes) -- so make sure you just look at one or the other or it's going to seem really confusing

[TechMage89]

O.K. I'll take a look at the Radeon stuff and try to get an idea of what's happening.

Whenever, I get the urge to muck around, though, it's always the memory stuff that frightens me away. I'm very much used to not having to worry about the details of memory allocation, and it scares me to have to try to make my code not overwrite some important part of memory.

I wish I could find some decent documentation about how drm in general and drm for ati cards in particular works, but I haven't been able to find anything but a very general description. I understand that it's been pretty primitive (static vram mapping to 2d, 3d, and framebuffer), but that TTM is supposed to be able to do it more intelligently (and make kernel console framebuffer drivers be more compatible). I haven't really been able to find out the details, though, and I'm not sure that much is correct. DRM's kind of being refactored right now, yes? I've heard it suggested that modesetting go into DRM, too to reduce the dependancy on X for graphics, but I gather that's not happing at this time.

[TechMage89]

It looks like copying, pasting, and cleaning code is out. I may have to write a new implementation from scratch for RadeonHD *sigh*. The code in the Radeon driver is quite messy, although not incomprehensible. I'm right now trying to get a grasp of what the registers do and reading the XAA docs to figure out how I should structure this. Now I need to take a look at the RadeonHD driver to see how it is structured.

If I can do really well on this, I may be able to accelerate line drawing in a week or so. As long as there aren't any memory allocation demons lurking. I'm still not sure I grasp that aspect of it.

[glisse]

I wish I could find some decent documentation about how drm in general and drm for ati cards in particular works, but I haven't been able to find anything but a very general description. I understand that it's been pretty primitive (static vram mapping to 2d, 3d, and framebuffer), but that TTM is supposed to be able to do it more intelligently (and make kernel console framebuffer drivers be more compatible). I haven't really been able to find out the details, though, and I'm not sure that much is correct. DRM's kind of being refactored right now, yes? I've heard it suggested that modesetting go into DRM, too to reduce the dependancy on X for graphics, but I gather that's not happing at this time.

We are already low on people and writing good doc take often more time than writing good code. But truely things are lot simpler than they look like. TTM & modesetting is happening right now. TTM is in master and it's api have been pushed to mm tree to get reviewed. For modesetting there is a modesetting-101 branch in drm git, it's were the code stand and where development happen. I will push this weekend i hope the new radeon drm driver with modesetting & TTM inside it (note that this is only DRM and that there is no userspace taking advantage of this right now).

[TechMage89]

If I get this figured out, I'll work on improving documentation. I think in the long run, that might be more useful than writing code. I think there are quite a few people who would like to work on Linux and X graphics, but they are often turned off by the lack of good documentation. It makes it much harder for a new developer to get started. I think I could improve this somewhat, as soon as I get it figured out myself.

[jealma]

Update driver

Hi, this new xf86-video-ati driver from GIT worked very well on my mobility x1400. I've downloaded the source from GIT, as explained in http://www.phoronix.com/scan.php?pag...item=921&num=1 . How can I use GIT to get the new sources and compile them, since I already have an old version installed?

[Kano]

Btw I tested the driver with atom bios with my X700 SE, it did not work via the dvi->vga adapter (which works usually better as it is the first connector) only via the 2nd pure vga one. Finally somebody pointed out that I could patch mesa to get rid of the rendering problem, as hotfix, which also worked. Now a "final" mesa patch would be good - currently all RV410 cards would run with half pipe setting that way (R300_GB_TILE_PIPE_COUNT_RV410 replaced by R300_GB_TILE_PIPE_COUNT_RV300). PCI ID: X700SE [1002:5e4f].