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.
Hm. Getting there? Hm. NT4? Hm. XP. Hm.
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" ?
Guys, Windows side has already moved on from XP/DX9 and modern games are being developed against DX11 API with DX12 upgrade coming soon.
Either Linux is VASTLY more efficient to be near-equivalent WITH the D3D-OGL translator, or translation is a tiny part of the work done, or the claim it is costly is a load of bullshit.
Given OGL windows games under Wine run faster (but not lots) than Windows, the likelihood is that the last clause is correct.
WHAT less to go wrong?
D3D lacks multithreading support (pre 11.1) but apart from that (which is a coding issue: if your code doesn't multithread its 3D graphics, then multithreading isn't used in OGL either), there's nothing more to go wrong.
For programming, they use different ideas, D3D being simpler for "boxed environment" 3D views, whilst OGL came from "proper" 3D modelling. But to the end used, neither have any difference.
PS on the docs, (other sub post), what a load of bullshit. d3d and OGL have equal documentation, he just knows where it is (and pays through the nose for it) with the windows product. The claim is entirely their lack of knowledge. Double bollocks on the back compatability.
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 ]