I was thinking of VirtualBox.
Announcement
Collapse
No announcement yet.
The Status Of Gallium3D Drivers, State Trackers
Collapse
X
-
Originally posted by wswartzendruber View PostI was thinking of VirtualBox.
Edit: Technically it might in time work if hooked up with Gallium3D but I've been hearing very contradictory opinions on whether these new CPU emulation technologies actually help at all with speed.Last edited by nanonyme; 08 August 2009, 10:06 AM.
Comment
-
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
~ C.
Comment
-
Originally posted by MostAwesomeDude View PostAll signs point to Tungsten/VMWare having an internal DirectDraw/Direct3D state tracker already, but they haven't confirmed this.
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.
Comment
-
Originally posted by nanonyme View PostAs 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.
Comment
-
Originally posted by Louise View PostWould MS be able in the future to forbid other implementations than their own?
Comment
-
One driver per ST per chipset??
Hi,
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!
Comment
-
Originally posted by Med_ View PostHi,
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.
???
Comment
-
Originally posted by nanonyme View PostAfaik no, the API is fully free to use. (which implies you're also fully free to implement it) It's mostly just that their implementation isn't free to use. (you need a valid Windows license to fully legally use Microsoft's DX libraries) That was Microsoft's decision long time ago that made development on Windows easier since every developer could just trivially look up the function descriptions from MSDN.
Comment
-
Originally posted by Med_ View PostSo 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!
Comment
Comment