If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

That'd be less native, not more.
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.

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

All signs point to Tungsten/VMWare having an internal DirectDraw/Direct3D state tracker already, but they haven't confirmed this.

Wonder if it's "DirectDraw/Direct3D-like" state tracker or the real thing. (just wondering because with the former you don't need WinAPI at all but might still get trivial mappings of functions and less trivial but still possible mapping of HLSL to TGSI and would work with all Gallium3D drivers)
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.

Would MS be able in the future to forbid other implementations than their own?

Afaik 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.

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!

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!

The way I understand it is, that e.g. in the case of "egl" state tracker that is DONE, this will also work for all the other GPU's once they get Gallium support.

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.

Afaik 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.

Cool. Also I guess if MS could forbid use of their API, they would have stopped WINE a long time ago

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!

You're reading the table wrong: It doesn't show the completion state of the state-trackers, but it shows the ability of the drivers to run the state-trackers. So there's really just one state-tracker for each functionality (which afaik are more or less complete), but the drivers are not yet able to run them.