Slashdot Mirror
Valve Open Sources Their DirectX To OpenGL Layer
jones_supa writes "A bit surprisingly, Valve Software has uploaded their Direct3D to OpenGL translation layer onto GitHub as open source. It is provided as-is and with no support, under the MIT license allowing you to do pretty much anything with it. Taken directly from the DOTA2 source tree, the translation layer supports limited subset of D3D 9.0c, bytecode-level HLSL to GLSL translator, and some SM3 support. It will require some tinkering to get it to compile, and there is some hardcoded Source-specific stuff included. The project might bring some value to developers who are planning to port their product from Windows to Linux."
Could this be of use to the Winelib project?
(As the name implies, it's the compile-time analogue of Wine.)
With a big company (in terms of money) like Valve pushing OpenGL there is a real chance DirectX will face serious and permanent competition. We will finally have a serious alternative to the suffocating model of forcing a new operating system down peoples throat through software. It worked great with the browser, now lets hope Valve can make it happen for games.
Valve makes money with Steam.
Valve has hammered out a useful content delivery platform for Linux and OS X.
Valve makes it easier to translate DX to OGL.
Collect profit... eventually.
Valves presentation on the topic http://adrienb.fr/blog/wp-content/uploads/2013/04/PortingSourceToLinux.pdf states better performance using togl for their games (togl starts at slide 18, performance is mentioned on 23).
If you are interested in this stuff, the Porting Source to Linux: Valve's Lessons Learned is also good watch, if you haven't seen it yet.
Yeah, probably minimal, since it is bytecode level (what HLSL and GLSL compile into)
The bad - this is DX 9.0c, which is analogous to OpenGL 2.0 (with extensions - note that ATI drivers didn't support extensions at the time, so more like 2.2+ for them) and in console terms, XBox 360/PS3 tech. OTOH, OpenGL went through a major paradigm shift with OpenGL 3 and 4 that make it work more like HLSL, so I expect shader conversion is much easier. When I ported a DX10 shader to OpenGL 3 it was much easier (but much harder was porting the entire OpenGL 2 project to 3).
Boobs
It runs on OSX and Linux, neither of which have native DirectX support because Microsoft keeps their graphics technology under tight wraps. All implementations of it not shipped by Microsoft need to be reverse engineered from the API. OpenGL is licensed to hardware manufacturers (which is how development is paid for) and accessing the API is free for software developers.
My guess it that they were doing a "two birds with one stone" strategy - using this project as an excuse (and test-case) for the translation layer, hoping that some devs would take this opportunity to port their DX9 games to Linux because of it, thereby improving the value of SteamOS.
Another option is that they didn't write DOTA2 from scratch, but reused an existing engine. Which in turn was based on some previous works, and at some point Direct3D was used, and remained there the whole time.
Going the other way like Microsoft does is more interesting.
One of the biggest issues with OpenGL is that you can get shaders that won't run in bounded time. You can see this with a number of games in Flash, or natively in OpenGL, when run on a Mac. If the shader doesn't exit, it eats a channel, and there are a limited number of channels, and once they are gone, the renderer, which is also used for the desktop, basically crashes. There are nice system log messages from the video driver about it, but besically everything ends up restarted, which is pretty useless.
FWIW: this accounts for the majority of system instabilities in the card specific portions of both Mac OS X and Linux render pipelines.
DirectX doesn't allow things to run in unbounded time in its OpenGL to DirectX translator; instead, it loop unrolls shaders, and if it can't do that such that they run linearly, and therefore in bounded time, it omits them from the render. So you might not get distance blurring, haze effects, fog effects, rain effect, and so on, but at least the thing doesn't crash, and if the person porting the code to the Windows platform cares about these things, they fix the code so that it'll run using DirectX. Usually, this reduced the perceived "quality" of the final render, but you get at least a crude version of your effect back.
The other thing DirectX does is, in the video driver, keep a reserve channel for sending commands to the video hardware; the common reason for this is in-band signaling to comply with the DirectX 9 requirement that the video hardware be capable of being reset, without rebooting the system, such that a video card hang doesn't necessitate a reboot.
While a DirectX to OpenGL translation layer is a nifty idea (I lobbied very hard for a FreeBSD emulator for Linux, rather than a Linux emulator for FreeBSD so that developers would target FreeBSD rather than Linux as their development platform), I don't think that as long as the OpenGL shader looping issues don't also get addressed at the translation layer that translating from DirectX to OpenGL will be in anyway superior to translating from OpenGL to DirectX.
So basically, it's nice they released this, but the code is of little practical use in the real world, since there are features that will get lost in translation.
Speaking as someone who's written a native D3D 9.0c implementation from scratch (on the PS3), implementing it is not the issue. I probably implemented the exact same subset as Valve did - only the shader-driven part, no fixed-function emulation - and it took maybe 4 weeks total (160 hrs). My implementation was 10x faster (seriously) than the D3D 9.0c implementation on X360. (That's CPU usage of the API; obviously the GPU ran at comparable rates. The X360 port team on the project I was on hit frame rate just issuing too many D3D calls, while the PS3 port was running the exact same D3D calls using 10% of the CPU. It correctly handled locking, sync, cache flushes, etc. so it gave the exact same guarantees as the real D3D; I guess Microsoft's 9.0c still had a lot of Windows cruft in it's X360 incarnation. Probably doing too many kernel transitions - I had zero except at the end of the frame.)
The reason I never turned this into a product and sold it was because to get the D3D 9.0c headers you have to accept an EULA that says it's all confidential, and my dog simply isn't in that fight. Valve's dog is in that fight now, but they have a much bigger dog than I do. Using their code as a starting point I could in theory release my code now (only to PS3 developers though because of Sony's NDAs ... and that's no click-through EULA, that's a cast iron contract between my company and Sony). A bit late though, who the hell needs D3D 9.0c on PS3 in 2014? Direct3D 12 on PS4, now that might be worth considering ...