Direct3D 9 Comes To Linux, Implemented Over Mesa/Gallium3D 138
An anonymous reader writes "Picking up the code from a failed Direct3D 10/11 implementation for Linux, a working Direct3D 9 state tracker has been implemented for Linux. The Direct3D 9 support works with open-source Linux GPU hardware drivers via Mesa's Gallium3D and can run games for the open-source Radeon and Nouveau drivers without simply converting the Direct3D commands into OpenGL. Unlike the experimental D3D10/11 code from the past, this D3D9 state tracker is already running games like Skyrim, Civilization 5, Anno 1404, and StarCraft 2. With Linux games not natively targeting D3D, Wine was modified for using this native Direct3D implementation."
Re:Year of Linux on the desktop (Score:2, Informative)
1998 called.. They want their joke back.
http://slashdot.org/comments.pl?sid=3963145&cid=44259321 [slashdot.org]
Re:simply... (Score:4, Informative)
The last line of the TFA implies that it's a performance issue; "It will be interesting to see if this Direct3D 9 state tracker takes off for Linux and whether Wine developers will optionally support it for better performance.". It would have been nice to have some more info on why this is worth doing though, it seems to be one of those articles written for people who already follow the subject, rather than casual readers.
Re:Yeah, if DirectX 9 had been around and not evol (Score:4, Informative)
Catchup for those not following the subject (Score:5, Informative)
it seems to be one of those articles written for people who already follow the subject, rather than casual readers.
Yup, indeed, it's just a small quick news on phoronix.
For the others:
- Mesa is the opensource 3d graphics driver used on Linux for opensource drivers.
(- the closed sourc drivers uses their own sauce instead)
- the old classic mesa is just a plain big monolith exposing OpenGL (that's what Intel provide for their official opensource drivers.
- the modern Gallium3D Mesa is a modular architecture for 3D API (that's what is used by modern opensrouce drivers, like the reverse engineered Nouveau for Nvidia, or the AMD-sponsored Radeon driver).
The idea of the Gallium3D modular design:
- on one side you have low-level drivers handling the hardware (or the CPU in the case of the LLVMpipe software driver) and exposing the basic GPU functionnality.
- on the other side you have "state tracker" high-level interfaces speaking the various API (OpenGL, OpenCL, etc.)
This make the whole development much faster and help code reuse.
- If a new hardware comes, you only develop a new low-level drivers exposing the functionnality of this new GPU. And bam! you get automagically support for any API for which you provide the necessary functionnality. No need to write a complete new OpenGL driver from scratch.
(That's how most of the newer opensource drivers, like all the new GPU for ARM SoC are implemented or are going to be implemented)
-If you want an additionnal API, you only develop a state-tracker, the high level part of Gallium which speaks the API. And bam! you get automagically support for any hardware whose low-level provide enough functionnality. No need to write a full Direct3D stack for each single available hardware, just write a generic stack for Gallium.
That's what is being done regarding DX3D9 in this news.
Up until now, the way 3D worked for Windows software running under Wine, is that wine has a layer that intercepts all DX3D calls and retranslate them into OpenGL then sends those to the running OS (to Linux or Mac OS X).
It works, but it's difficult, and it's slow: this translation layer comes at a cost. Even more so because OpenGL and DX3D do not function in the same way, so implementing some stuff requires quite a complicated translation.
Now this Gallium stack is much more direct, it receives Direct3D calls and directly execute them using the low-level functionnality exposed by a hardware layer. It doesn't need to go throug a complex intermediate translation step.
The advantages of this approach are:
- It's much faster that way, because we directly call hardware function, instead of having to map to concept from another API (openGL) which doesn't work the same way.
- It's quick to develop, specially because Gallium has already support for most of the needed functionnality to provide Direct3D 9 (unlike an older Direct3D 10/11 driver which were attempted earlier).
- For older Radeon hardware, the opensource driver is what AMD recommand, they are stable enough, fast enough, and still maintained. So you're probably getting near native spead when running windows software on linux through wine, instead of slow down due to the opengl translation layer of wine.
The problems of this approach are:
- It only works with Gallium.
- Intel official opensource driver don't use it (but there are attempts by 3rd parties to make gallium drivers)
- AMD official drivers for current modern hardware is the closed-source catalyst (their own different stack).
So either you get fast up-to-date Catalyst drivers, which only speak OpenGL and you have to put through with the wine translation layer. So you lose performance.
Or you use experimental not-yet stable opensource drivers, which are gallium and thus do speak Direct3D 9, but they aren't perfected yet and are slower than Catalyst. So you lose performance too (albeit at a different level)
(At least, on the radeon side, AMD is collaborating a
"DirectX is at 11 now" (Score:5, Informative)
How many people still like to play games that are 5..7...10 years old. A lot of people
Even relatively modern games like Civ 5 and WOW are quite happy with direct x 9.