Slashdot Mirror
Direct3D 9.0 Support On Track For Linux's Gallium3D Drivers
An anonymous reader writes Twelve years after Microsoft debuted DirectX 9.0, open-source developers are getting ready to possibly land Direct3D 9.0 support within the open-source Linux Mesa/Gallium3D code-base. The "Gallium3D Nine" state tracker allows accelerating D3D9 natively by Gallium3D drivers and there's patches for Wine so that Windows games can utilize this state tracker without having to go through Wine's costly D3D-to-OGL translator. The Gallium3D D3D9 code has been in development since last year and is now reaching a point where it's under review for mainline Mesa. The uses for this Direct3D 9 state tracker will likely be very limited outside of using it for Wine gaming.
Apparently up to this point in wine D3D 10 had more complete support than D3D 9. Is there a reason why it would be useful to make D3D 9 support more complete? I understand that this article goes beyond Wine.
If you have a working D3D 9 implementation, you've also covered practically everything needed to support D3D 5 - 8 as well. This will get you pretty good coverage of games and other 3D apps released from 1998 to at least 2011.
D3D 10 was a significant break from both the API perspective and in terms of how it works underneath. D3D 10 was included with Vista but never made available for Windows XP (because it relied on kernel changes and a new driver model that couldn't be backported) so game developers took their time in moving to it.
Is there a reason why it would be useful to make D3D 9 support more complete?
Games only started using D3D 10/11 *very* recently -- the back catalog this could enable is huge, and D3D 9 games are still coming out today. It'd say it's very important to support.
This support in mesa will allow these games to be ported more easily, rather than forcing a rewrite in a major portion of any game engine, the display layer.
This won't help much for porting. It only works for drivers that work on Gallium3D. Thus, it only works on Radeon and Nouveau (and the alternative Gallium3D powered ILO. The official Intel runs on classic Mesa).
So only a very few end users will be affected. It's not worth counting on Gallium Nine for the port, as you're missing the big part of users who instead run the proprietary and/or official drivers (specially since Nvidia's blob has way much better hardware support that the reverse engineered Nouveau - due to lack of documentation).
On the other hand, Gallium3D give a nice and faster route for Wine, so a few select users can get straigh Direct3D support instead of going through a transaltion layer. So it's a relative benefit for Wine itself.
The developer can even choose to go the wine route, and simply provide a wrapper for their product, such as Star Trek Online uses with thier Mac port.
That has technically been possible before the Gallium Nine driver, anyway. The presence or absence of this driver don't change the feasibility of such ports. It only makes them faster for a few select users by removing translation layers.
This may be hugely important for the Steam Box initiative.
Well, depends. I doubt that, when it comes out, it will rely on opensource drivers. At least not for Nvidia hardware: the difference of stability and hardware support isn't worth the effort.
On the other hand, if AMD get their shit together in time, and release the hybrid closed/source driver as promised (i.e.: you run the opensource kernel driver "amdgpu". Then, as an OpenGL implementation, you're free to use either the opensource Mesa Gallium3D driver or the Catalyst driver which will only be a GL+CL library running on top of the exact same opensource base), you might see the possibility of AMD Steamboxes that let the user switch between the two GL implementation on the go. That could mean using opensource GL/CL for the interface and for a few select game that need DirectX, and switching to Catalyst GL/CL for games that need GL 4.x, with Steam maintaining a database of which version runs better for which game and handling the switching without need of user intervention.
Over all, Direct3D is a much simpler and lower level API (at some point of time it was considered to be a back-end to be targeted by openGL drivers) so it would be supported faster than openGL and would give definitely a performance boost.
Also, specially if AMD releases Mantle for Linux (or if it becomes "OpenGL Next"), that might attract the interests of some multi-platform developers: such AMD powered Steamboxes would be closer to the hardware found in other consoles (AMD APU or GPU in all other consoles of this generation) and might help PC ports (at least on AMD it might get optimised a bit thank to re-using the work done on consoles).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Also documentation. Say what you will, D3D's docs are lightyears ahead of the messy, poorly-versioned documentation for OpenGL. Doesn't help that OpenGL kept backwards compatibility for so long that even fairly recent tutorials still use the horrendous immediate mode either, making tutorials for modern OpenGL harder to find. Meanwhile, Microsoft's SDKs have extensive tutorials and samples, and there's plenty of references to start from especially now that DirectX 10+ have slashed out all the crap accumulated from older versions.
Just use this as an example: search on Google for glVertex. First link goes to the official documentation. Nowhere on the page is it mentioned that this entire rendering system has been deprecated. Nowhere on the page can you see that the documentation is for OpenGL 2. There's a 2 in the URL, but changing it to a 3 or a 4 gives a 404 error. At least now some blessed soul made docs.gl, but the fact it's not even Khronos taking some time to fix their fucking documentation is absurd. You'll note though that even there, the docs for glVertex don't mention deprecation; the function just doesn't have an OpenGL 4 page.
Then there's debugging. Once you've used PIX or VS2012's built-in debugger, you really can't look back. Being able to save any frame, step through the entire rendering process event by event, and even go as far as debugging an individual pixel (down to what tried to write on the pixel, why the draw call did or didn't pass, and a way to put breakpoints in shader code using that pixel's input and output!) is just... It's unrivalled. Nothing from OpenGL even comes close to this.