The UVD answers are interesting, although I have to wonder how much of that is due to a lack of any licensed players for Blu-ray or HD-DVD under Linux.

I wonder what "significantly smaller" will turn out to be re new gen initial Linux driver releases gap vs Windows?

I nearly linked this as an example of the gruesome past somewhere in the body: http://forum.beyond3d.com/showthread.php?t=28627

But decided out of consideration for Pete's new role not to. :razz:

Still, that one turned out to be 6 months. Ouuuuuch. Personally, while simultaneous would be great and ought to be the target, I'd think even 4-6 weeks after initial availability would be liveable for most folks.

We should try and bring the OpenSource developers into this discussion, I think.

Good idea. Anybody know some to invite to the discussion?

You should be able to find them on freenode IRC.

On #radeonhd libv, egbert and emmes are the primary developers of the new radeonhd driver.

On #radeon, agd5f and airlied are the primary maintainers of the pre-5xx radeon driver, which has now started to pick up 5xx/6xx support as well.

Kind of scary to think that a driver for a graphics card with DirectX 10 (and 10.1 in later models) level hardware would be resorting to using LLVM to run-time compile shaders to run on the CPU.

I don't think that's quite what he was suggesting, Tungsten Graphics are actually using LLVM to generate code to run on GPUs. Intel for the moment, but since the R600 ISA is open now they could presumably do the same for that.

FYI we released initial open source support for using the 3D engine on 6xx/7xx hardware yesterday. The driver code is very preliminary but it makes the 3D engine work and there is a demo program showing how to do most of the common 3D functions. Code is up on freedesktop.org in the mesa/drm, mesa/r600_demo and xorg/driver/xf86-video-radeonhd projects. For drm and radeonhd we put the code in branches until it gets more testing & fixing.

The register spec document didn't get through review in time but all of the register names, offsets, field names and shift/mask data from the document are in the header files. For anyone so inclined, this plus the existing r600isa doc should provide enough information to do both 3D driver work and GPGPU work.

More details on Phoronix, Matthias's blog (http://emmes.livejournal.com) and Dave's blog (http://airlied.livejournal.com) plus the usual IRC traffic.

Next steps are to fix the holes in the EXA/Xv driver code and to get an initial Mesa implementation by adding 6xx/7xx programming sequences for the current 5xx functionality (including a generic shader assembler). We'll probably jump across to Gallium3D after that and do all the subsequent 3D work using Gallium3D.

I'm on the LLVM mailing list, and was actively watching it not to long ago, if I'm not mistaken, there are a fair number of efforts targetting GPUs. Gallium3D being just one.