I was thinking of VirtualBox.
I was thinking of VirtualBox.
All signs point to Tungsten/VMWare having an internal DirectDraw/Direct3D state tracker already, but they haven't confirmed this.
Mesa's core has already been adapted into a state tracker for OpenGL 1.0-2.1 support. A few developers (mostly idr and osiris) have been submitting patches for various extensions belonging to OpenGL 3.x. Fortunately, it looks like we're not too far behind the ball this time; the important stuff, like FBO handling changes, will be really easy to adapt to, since we're using real memory managers on the Gallium drivers.
I seem to recall zackr mentioning that somebody was working on an OpenCL Gallium state tracker. Also, the preferred video decoding interface would be VDPAU; supporting it or either of the other two advanced video APIs (VA-API, XvBA) will require augmenting g3dvl with a true pipeline. (If you're serious about this, ping me and ymanton on IRC. #nouveau or #dri-devel.)
Regarding writing Gallium code... There's really no way around reading the code, but I'll give you a few places to start. Read the headers in src/gallium/include/pipe/p_*.h. The main class of drivers is pipe_context, which contains a few dozen methods for setting state and issuing draw commands. There's also pipe_screen, which contains things like the capabilities of the card you're on, and buffer management.
If you're writing a driver, you'll probably fill out your pipe_screen, and then your pipe_context, and most of the code you write will be for managing the state connected to the pipe_context.
If you're writing a state tracker, you'll want to get a pipe_screen and pipe_context, and then send drawing commands to it, while interfacing with your frontend.
The API is constantly shifting bit by bit to be more sane, but all drivers and state trackers that are in-tree enjoy maintenance and testing on a semi-regular basis, just like the kernel, so it's really not that bad. (I don't know anybody actually using the Cell driver except for the occasional guy on the mailing list, but it still receives updates and API fixes.)
Again, if you're serious about writing code, come into #dri-devel; we're more than happy to help you start understanding the code. :3
As in, something that's easy to wrap up with VMWare virtualization products later on to get a code path without OpenGL in-between there. Would be a good thing in any case.
There is something i do not quite understand in this matrix. I thought the aim of Gallium was to write only one driver per pipe and once this driver written, all state trackers would work automatically, unlike current mesa in which you have to rewrite all the stacks in each driver. So why is it that the completion state for each state tracker depends on the pipe? It looks like we are losing the advantage of gallium but i must be misunderstanding something. I would appreciate if someone could explain me where i am wrong. Many thanks!
If that's the case, perhaps it would be more clear to just color the titles, and then just set X once the GPU have Gallium support and the particular state tracker have been written.