Originally posted by iznogood
View Post
- 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.
You would need to configure X to use the "xorg state tracker" driver rather than your existing X driver (radeon/radeonhd).
Originally posted by iznogood
View Post
Originally posted by Zhick
View Post
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.
Leave a comment: