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.
Maybe it's because I tend to play old games, but my perception of it hasn't so much been costly as explodey. Or sometimes it just draws stuff wrong, but I can mostly live with that.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
I bet there are lots of other applications that utilize d3d and want to port to linux that can use this directly.
I've met people that actually prefer d3d over opengl (don't ask me why), so I think it's going to have much wider use than wine.
It would be nice if support for Glide 2.1 and 3.0 be added also, there is a good chunk of oldies that would benefit and nowadays wine has dosbox built in, so even DOS games would be supported.
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 ]
It would be nice if support for Glide 2.1 and 3.0 be added also, there is a good chunk of oldies that would benefit and nowadays wine has dosbox built in, so even DOS games would be supported.
Very unlikely in my opinion:
Voodoo cards (and their Glide API) are fixed pipeline.
Whereas, from the ground up gallium3D was organised around the modern features found in a programmable-shader card.
There's a lot of difference between how these work.
On the other hand, Glide was designed with the simplest subset of OpenGL implementable in hardware in mind. That's why it easy to write miniGL or OpenGL implementations on top of it (and the reverse also: it's not impossible to write Glide-to-OpenGL wrappers).
Meaning that, in theory, it could be possible to build a Glide state tracker out of the building block that Gallium3D back-ends expose to the Mesa OpenGL tracker.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
"There's patches" ?
DX12 is highly unlikely to become popular any time soon because of the whole 7 uber alles situation. At best, it'll be where DX10 was.
DX11 while popular is not mandatory for most games that come out. A lot of games still have separate DX9 and DX11 rendering paths. As a result, while you'll have to give up some bells and whistles you will be able to run the game just fine as long as you have DX9 rendering path available.
There are some games that require DX11. Those are usually latest and greatest that require decent hardware as well. But these are far from the most played games out there. Making a quick list of the few games I played during last month, several have both rendering paths (and in one, I actually use DX9 instead of DX11 because DX11 path is much more buggy), several don't have DX11 path at all, and one doesn't have DX9 at all.
Internally windows system calles work a lot like WINE on linux. https://en.wikipedia.org/wiki/...
But unlike windows Linux doesn't have to drag along all the legacy binary support for some of the lower layers.
Again, there's a reason why Glide wrapper tend to target OpenGL 1/2 instead of 3/4.
Glide is fixed pipe.
Glide and the other APIs back then (DirectX 7, OpenGL 1/2, etc.) where about just painting plain triangles. Paint triangle with tips at vertex v1,v2,v3 using texture T1, optionally a second texture T2 as lightmap (and for the few architecture that did have it: using a third texture T3 as a bump map).
That's it.
For any pixel on the screen, the only thing the hardware is capable of is geting 2 or 3 textures (interpolating them and mipmaping them), and combine these 3 texture in a hardware specific and fixed way.
Modern APIs (OpenGL 3/4, DirectX 9, and 10/11, Mantle) are all about programmable shader. For any pixel on the screen, you run a small program (a kernel in mathematics) which can do pretty much anything you want. You can ask the hardware to draw pretty much anything you want. You could even ask the hardware to draw a mandelbrot set (I've done that).
Your modern API relies on a back-end that export the functionality of these general-purpose highly parallel processor that are GPU (Gallium3D is exactly such a back-end. DirectX 11, Mantle, and OpenGL Next are API that promise to stay as close as possible to this low level) (and OpenCL is a way to make this available for other kind of general purpose computing). On top of it, it has a high level API that still works in a highly customisable way: you write shaders that will combine several texture in the way the artist would need (including effects like occlusion mapping, translucent and sub-surface scattering, etc.) and the API converts these mid- high-level shaders and texture accesses, into lower level kernels and memory access to generate whatever is needed on the screen, no matter how complex the maths behind are. (remember: a Mandelbrot set is perfectly doable, even if completely useless).
That's also why DirectX state tracker makes a bit sense: DirectX is supposed to be a little bit less high-level on the abstraction scale than OpenGL. It's better to DirectX-to-Gallium3D (would be like translating C into assembler as a regular compiler), rather than DirectX-to-OpenGL (would be like translating C into Python).
Glide on Gallium3D, would mean rewrite a complete fixed pipeline. Expressing all the classical "texture and lightmap" combination which back then were handled by hardware, and writing modern shaders that re-implements them. Well, guess what? Drawing polygons with a fixed pipe-line is already what OpenGL 1/2 does inside Mesa on Gallium.
Instead of rewriting the same stuff twice and risking to introduce twice as many bugs, simply use a Glide2GL wrapper. Glide and OpenGL are very closely related anyway.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
What can go wrong? How about all the bugs in random gl drivers from various vendors? Oops this only works on nvidia, this only works on ATI (haha yeah right nothing works properly on ATI), intel is a joke, etc, etc.
Mod me down, my New Earth Global Warmingist friends!