ATI R300-R500 Gallium3D Driver Is "Mostly" Done

[phoronix]

Phoronix: ATI R300-R500 Gallium3D Driver Is "Mostly" Done

It has been a while since talking specifically about ATI's Gallium3D driver, but there is some good news coming out now for the driver that supports the ATI R300 through R500 (Radeon X1000) series hardware. Corbin Simpson, the developer that has largely been working on porting the 3D work from the classic Mesa driver to Gallium3D, has updated the Radeon Feature Matrix page on the X.Org Wiki last night.According to this update, the status of Gallium3D on ATI R300 through R500 hardware has changed from "TODO" and "WIP" to being "DONE" for the Softpipe pass-through and being "MOSTLY" for the core driver...

http://www.phoronix.com/vr.php?view=NzYwMA

[Zajec]

The ATI Gallium3D driver that supports the R600 and R700 (and R800) hardware is still being worked on as well.

Could you share source of that information? AFAIK AMD wants to /finish/ r300g first, to learn what should be avoided when writing r600g. I was eve talking with Bridgman about this yesterday.
So, where did you get that info?

[iznogood]

Hello,

thanks for the updates on the ati driver status. Can someone explain what features is gallium going to offer against the mesa driver ?

I read the matrix but i do not understand what parts of the mesa driver are going to be replaced by the gallium driver. For example is it going to replace only the mesa 3d features or other parts of the matrix as well like XXA - EXA acceleration and xv - xvmc video support ? I don't really understand how gallium is working on the existing graphics stack.

Also i want to ask why there is no gallium on r100 chips?

Finally, i tried to check on the feature matrix of the intel driver http://www.x.org/wiki/IntelGraphicsDriver but it seems that no one is updating this.

[Michael]

Could you share source of that information? AFAIK AMD wants to /finish/ r300g first, to learn what should be avoided when writing r600g. I was eve talking with Bridgman about this yesterday.
So, where did you get that info?

It's being worked on still as in it's not done yet either.

[DanL]

Michael, I think Zajec is asking where the r600 gallium work is happening (if it is happening). http://cgit.freedesktop.org/mesa/mes...allium/drivers

[Louise]

Michael, I think Zajec is asking where the r600 gallium work is happening (if it is happening). http://cgit.freedesktop.org/mesa/mes...allium/drivers

I think he just made that up.

If someone was working on it, Corbin would have changed the state from TODO to WIP.

[Ant P.]

I think he meant still being worked on as in they haven't forgot about it and it'll get done eventually.

[Zhick]

So what does this mean? Does this get us OpenGL >= 2.0 (and most importantly GLSL) now? Or is there still work that needs to be done for this, except of debuging of course?
I had the understanding that as soon as the Gallium3d-driver was done one should be able to just use the OpenGL 2.1 etc state-trackers on it. Is this really something we can expect to be working in the foreseeable (say 3 months) future? If so then development is much faster than I anticipated.

[bridgman]

I read the matrix but i do not understand what parts of the mesa driver are going to be replaced by the gallium driver. For example is it going to replace only the mesa 3d features or other parts of the matrix as well like XXA - EXA acceleration and xv - xvmc video support ? I don't really understand how gallium is working on the existing graphics stack.

The Gallium3D driver does two things :

- replaces the existing Mesa HW driver API with a new API designed around programmable shaders rather than a fixed-function 3D pipeline
- provides a driver API which is sufficiently generic that it can be used for more than just 3D, eg EXA, Xv, video decode etc..

The most important thing to understand is that Gallium3D is not a replacement for Mesa itself, only for the HW driver layer inside Mesa (ie the src/mesa/drivers sub-tree). The upper level Mesa code (which is what actually implements the GL API) calls Gallium3D drivers rather than classic Mesa HW drivers.

There is a project in the Mesa tree called the xorg state tracker. This is an X driver which calls into KMS for modesetting and uses Gallium3D for EXA and Xv acceleration. The xorg state tracker (aka st/xorg) is the "missing link" which plumbs the non-3D parts of the graphics stack into Gallium3D.

http://cgit.freedesktop.org/mesa/mes..._trackers/xorg

You would need to configure X to use the "xorg state tracker" driver rather than your existing X driver (radeon/radeonhd).

Also i want to ask why there is no gallium on r100 chips?

The Gallium3D API is designed for shader-based GPUs starting with approximately DX9 functionality. The R300 was the first ATI GPU with DX9-level shaders. The R100 basically had no programmable shader hardware. The R200 had a fixed function pipeline *and* DX8-level shader hardware. Right now the plan is to support r300 and up with Gallium3D, then go back and look into whether a subset of Gallium3D could be useful on older parts.

So what does this mean? Does this get us OpenGL >= 2.0 (and most importantly GLSL) now?

GLSL is somewhat orthogonal to Gallium3D. The shader compiler is common between classic and Gallium3D drivers; nhaehnle has been looking into adding the necessary support for GLSL to the shader compiler but I think there's still a fair amount of work to be done. In theory the rest of the GL 2.x functionality should come along more or less for free with a Gallium3D driver but I expect every new GL feature will require some fixing.

The most important milestone, however, is getting 300g to the point where 3xx-5xx users can switch over to using the Gallium3D code as their primary 3D driver - IMO that's the point where you'll see all the developers pile onto Gallium3D and work there rather than on the classic mesa driver.

That is also the point where it seems to make sense to start merging the classic r600 driver and Gallium3D 300g driver to make a 600g driver. In the meantime, Richard is working on adding support for flow control instructions to the 6xx/7xx shader compiler as a first step to supporting GLSL on the 6xx and higher parts.

[marek]

In theory the rest of the GL 2.x functionality should come along more or less for free but I expect every new feature will require some testing and fixing.

However, there is a little problem. As far as I know, r3xx-r5xx does not fully support non-power-of-two textures (e.g. the repeat wrap mode and mipmapping) and it is the prerequisite for GL2.0. If r300g gets GL2.x, this will imply falling back to software rasterizer in some situations, as was done in the proprietary drivers, am I right? Or will developers stick to GL1.5 + GLSL? I guess violating the GL spec in order to get GL2.x is out of the question, but that would be a pleasant solution in practice because people could use a newer GL API than what they have now.