What can I expect from 3D radeonhd?

[wiscados]

When the radeonhd driver will get 3D support, what should I expect?
Currently fglrx is not too good, not compared to nvidia.

Does the radeon driver have better 3D support than fglrx?

Of the documentations that have been released, has any been 3D documentation?

[bridgman]

It has 3d support today for 5xx, although it's pretty recent and there are problems using 2d and 3d together (which are being dealt with now).

It's useful to understand that there are actually 3 drivers working together :

- the x driver (radeonhd or radeon) which handles display setup, modestting, 2d and video acceleration, in the freedesktop.org tree at xorg/driver/xf86-vide-radeonhd or xf86-video-ati (radeon)

- the drm driver (mesa/drm) which is essentially the kernel driver, required for 3d acceleration, optional for 2d & video acceleration but tends to make them faster and more reliable

- the 3d driver (mesa/mesa), which executes the actual OpenGL 3d drawing commands

re: fglrx vs radeonhd/radeon, depends what you mean by "better". The fglrx 3d is faster and supports more OpenGL extensions, but the radeon/radeonhd 3d is open so if it has problems with your specific system it's easier to get help making it work, and it's easier for application developers to work out compatibility issues

We have released full 3d documentation for 5xx, and started releaseing 6xx 3d docs (only about 30% so far). Look in www.x.org/docs/AMD/

[d2kx]

I am looking forward to try the new stuff out when it's all in the stable Radeon(HD), Xorg and Mesa releases, but am wondering how many improvements for R500 3D there are still to be made? As far as I know, there isn't a memory manager yet, is there any other big work that has still to be made for R500 3D? Will bigger applications and games like ET: QW work in the future (haven't worked in Michals initial R500 3D review)?

[bridgman]

There are lots of improvements which could happen with the current 5xx 3d implementation (you can read what nh_ and MostAwesomeDude are doing on #radeon or #radeonhd irc at radeonhd.org); lots of changes in just the last couple of days.

As to "how far can it go" it's probably approaching the point where it makes more sense to jump onto Gallium and build there, but that's not a hard, clear line -- just a point where you start to suspect that you're inventing something which Gallium already has.

I expect 5xx will go a lot further, certainly to GL 2.x, just not sure it makes sense to get there on the current code base. Once we get some 6xx 3d to the same level that 5xx is today (yesterday, I guess; it's further today ;)) I expect we'll mostly jump onto memory manager and Gallium.

[d2kx]

Sounding great :D

Sometimes I think your job at AMD is to be a community manager. You make a much better marketing guy this way, too :)

There should be an own thread to let everyone thank you for your detailed replies.

[yoshi314]

There are lots of improvements which could happen with the current 5xx 3d implementation (you can read what nh_ and MostAwesomeDude are doing on #radeon or #radeonhd irc at radeonhd.org); lots of changes in just the last couple of days.judging by recent mesa commits, they're hacking like crazy on it ;-)

[d2kx]

I hope that it all will be integrated into Mesa 7.1, even the newest commits...

Btw., does it already use DRI2 so that Compiz + 3D or video work together at this stage?

[bridgman]

Good point - not sure what Brian's plans are for wrapping up 7.1, maybe he's waiting for MostAwesomeDude to sleep ;)

Pretty sure it's not using DRI2 -- that would need coordinated changes in X driver, drm and mesa AFAIK. It does seem like a good time to be looking at that though, I agree.

[NeoBrain]

A bit OT, but what's the state of the Glucose project and its implementations in the open source drivers at the moment (especially radeon/radeonhd)?

[bridgman]

Glucose needs to be built on top of a working OpenGL driver, so getting GL running on 6xx still needs to be top priority. Once OpenGL is there Glucose becomes do-able.

What I don't have a good feel for is whether Glucose offers any real advantages over EXA other than avoiding the need to implement EXA in the first place.

[TechMage89]

I think EXA works better than glucose would on the radeon driver at any rate. Glucose probably will not be widely used, because once things get implemented on gallium, render acceleration can just be implemented generically on top of that, instead of having to mess with an OpenGL layer, too.

[bridgman]

Agreed. I guess it's possible for a 2d-over-GL or 2d-over-Gallium driver to be better if the underlying driver had a better shader compiler or something, but the shaders are pretty simple and it seems unlikely that anything would beat a straightforward EXA implementation as long as the full API was supported.

I think the big argument for Glucose (or equivalent over Gallium) is that if you compare "one set of code runs on all GL drivers" Glucose acceleration over "easy in principle but nobody had time" EXA drivers, Glucose wins every time. That's actually a pretty fair point if you look at how few GPUs have full EXA implementations.

[TechMage89]

True, that. I think render over Gallium may be a better idea than render over opengl, though, because it gives finer-grained control, and makes one not such a slave to the state machine. However, I think if someone had time to make gallium, they probably had time for EXA, so there may be no point (witness nouveau, radeon someday, intel) Older, less common drivers may just be stuck with XAA (eg. savage)

[duby229]

Can you really blame them though? Maybe if S3 or SIS or any one of these littler graphics companies get there shit together, and release a truly competitive product then it may be a good idea to update the driver to a more recent code base. Until then though the majority of development efforts should be made towards ATi, nVidia, and Intel. These are the three biggest companies to date, and they should receive the most attention.

[l337programmer]

There are lots of improvements which could happen with the current 5xx 3d implementation (you can read what nh_ and MostAwesomeDude are doing on #radeon or #radeonhd irc at radeonhd.org); lots of changes in just the last couple of days.

As to "how far can it go" it's probably approaching the point where it makes more sense to jump onto Gallium and build there, but that's not a hard, clear line -- just a point where you start to suspect that you're inventing something which Gallium already has.

I expect 5xx will go a lot further, certainly to GL 2.x, just not sure it makes sense to get there on the current code base. Once we get some 6xx 3d to the same level that 5xx is today (yesterday, I guess; it's further today ;)) I expect we'll mostly jump onto memory manager and Gallium.

Can you tell me if you will have initial support for Xen in the memory manager? Being able to partition the graphics card into a virtual half would be amazing.

[glisse]

Can you tell me if you will have initial support for Xen in the memory manager? Being able to partition the graphics card into a virtual half would be amazing.

I don't think that such things will happen in near future, on the other end i know that some of the people working on virtualization are trying to find out if they could abstract video card through gallium to enable acceleration in the virtual environnement what ever is the underlying card.

[l337programmer]

I don't think that such things will happen in near future, on the other end i know that some of the people working on virtualization are trying to find out if they could abstract video card through gallium to enable acceleration in the virtual environnement what ever is the underlying card.

I've done several hours of research on this matter, and apparently with an IOMMU, most of the memory problem is solved. This (http://readlist.com/lists/lists.xensource.com/xen-users/3/15680.html) is an interesting read.

This guy (http://wiki.xensource.com/xenwiki/CoolConfigurations#head-f4e3242c0008f33dfe01a8467a011efad1723ad2) has two nVidia 7800GTXs installed and running two separate instances of UT2004 at the same time on one physical machine. His DomU and Dom0 are both FC5. I'm 90% certain his machine doesn't have an IOMMU, however.

I was thinking a software IOMMU might be able to be implemented in the Xen virtual 3D device for systems that don't have a hardware one for the XP drivers to interface with. Unfortunately I am not a very skilled coder, or I would at least take the time to read through the code and see what I could do myself.