Thursday, March 13th 2014

Valve Runs a Direct3D to OpenGL Translation Layer

Digging through the source code tree of Dota 2, developers discovered Valve's latest creation, ToGL. Simply put, it's a Direct3D to OpenGL translation layer, which works to reduce duplication of effort in developing games for multiple platforms (such as Windows, Linux, and OS X). The software can translate Direct3D calls to their OpenGL analogues. So far, it can translate only certain kinds of calls within the Direct3D 9.0c API, which should fit Valve's needs adequately. It features a bytecode-level HLSL to GLSL shader language translator. It features only a limited shader model 3.0 support. ToGL is currently being provided by Valve as-is on GitHub, and is unsupported. Developers are free to incorporate it into their projects, and make modifications to it.

Source: GitHub
Add your own comment

22 Comments on Valve Runs a Direct3D to OpenGL Translation Layer

#2
john_
This looks like the opossite to Scitech GLdirect that was translating OpenGL to DirectX in Windows.
Posted on Reply
#3
BiggieShady
I suppose this is specifically for dota2 linux port .... wonder if it could be used to port all those games that are already xbox 360 ports :laugh: wonder how a bad port of a bad port would be like
Posted on Reply
#4
Easy Rhino
Linux Advocate
with this and the crytek engine available on linux it looks like easy rhino was right 5 years ago. please bow down.
Posted on Reply
#5
ne6togadno
valve is working to make soruce 2 linux capable and then port all source 2 based games to linux
Posted on Reply
#6
TRWOV
I don't know if this will affect much. Cedega is more mature, has been around since like forever and I can only think of one game that has used it.
Posted on Reply
#7
sneekypeet
Unpaid Babysitter
How about we all stop calling each other trolls or whatever name it is at the time and move on!
This is a polite warning to everyone, move along, nothing to see here!
Posted on Reply
#8
Tatty_One
Senior Moderator
I never cease to be surprised that so much ignorance can fall upon one thread like flys around s**t, a warning was issued a while back, it has been ignored, so sadly pain is a coming, any more crap in here and we wont be talking modest 45 day holidays....... Thank You.
Posted on Reply
#9
damric
Does this add even more CPU overhead?
Posted on Reply
#10
Aquinus
Resident Wat-man
by: damric
Does this add even more CPU overhead?
Any compatibility layer is going to add some level of overhead. I'm curious if it's going to perform well.
Posted on Reply
#11
TRWOV
by: Aquinus
Any compatibility layer is going to add some level of overhead. I'm curious if it's going to perform well.
Cedega 6.0 was reporting >90% native speed on some titles (Enemy Territory, WoW, etc.) but that was 4 years ago, not to mention that these translators support up to DX9c.
Posted on Reply
#12
TheinsanegamerN
by: damric
Does this add even more CPU overhead?
in this day of 7 year old core i7 cpus being capable of running modern games at 60fps, I doubt that the cpu overhead of a program like this would really make any kind of sizable impact on any halfway modern gaming system.
Posted on Reply
#13
Scrizz
by: TheinsanegamerN
in this day of 7 year old core i7 cpus being capable of running modern games at 60fps, I doubt that the cpu overhead of a program like this would really make any kind of sizable impact on any halfway modern gaming system.
7 year old??
Posted on Reply
#14
xBruce88x
yep... they're getting that old now. though 6 yrs not 7.
Posted on Reply
#15
TheinsanegamerN
by: xBruce88x
yep... they're getting that old now. though 6 yrs not 7.
well..guess I should leave the counting to the i7 as well. It's amazing how long those things have been around and they still can run just about anything.
Posted on Reply
#16
RejZoR
This is so going in the wrong direction. Instead of using direct HW acceleration through metal API's, they are now doing rendering through several extra layers of API's. How stupid is that, all with excuse they don't have to make double work. That's how console ports are born and i don't have to say it twice, they are all rubbish. I miss the days when games had engines designed from ground up to run on both Direct3D and OpenGL from day one. Remember all the Unreal Engine based games from 1999-2003 or so?
Posted on Reply
#17
Aquinus
Resident Wat-man
by: RejZoR
This is so going in the wrong direction. Instead of using direct HW acceleration through metal API's, they are now doing rendering through several extra layers of API's. How stupid is that, all with excuse they don't have to make double work. That's how console ports are born and i don't have to say it twice, they are all rubbish. I miss the days when games had engines designed from ground up to run on both Direct3D and OpenGL from day one. Remember all the Unreal Engine based games from 1999-2003 or so?
I disagree, if they can get close with minimal overhead, that save a lot of programming hours porting an engine from one 3D API to another. While it might be slower, it's a step in the right direction. It also create a framework for how to port DX applications to OpenGL since there is a library that does the translation for you.

The real question we have to ask (before we start bashing it,) is what kind of performance will we see out of this compatibility layer. Until our questions are answered we shouldn't judge it. Additionally, it's a lot more than double work to port a game from one API to another. Consider for a moment how many bugs and incompatibilities you come across between the two APIs then remember that they need to thoroughly test it once they even get it working.

This makes sense for games that were coded for DX and only DX to run in OpenGL. I don't see the problem with that. It's giving you an option where you wouldn't otherwise have one.

Don't like it? Make your own damn 3d engine. :p
Posted on Reply
#18
RejZoR
Sure, Direct3D also had "minimal" overhead which now turned into a massive one...
Posted on Reply
#19
Aquinus
Resident Wat-man
by: RejZoR
Sure, Direct3D also had "minimal" overhead which now turned into a massive one...
Please start citing your sources if you're going to make claims like that. DX interfaces with hardware-level APIs so overhead will be minimal anyways in most cases, so I'm reluctant to believe that. Any API call is going to have some overhead and take some time to call it, but taking time to call an API doesn't mean that it has a lot of overhead. Some API calls are just simply costly.
Posted on Reply
#20
olstyle
As far as I understand from a short look in the source, this wrapper is used at compile-time.
This means that there is no overhead for redirected calls at runtime, but you need the source of a game to make use of it.
I'd still expect a slight performance hit compared to native OGl though. Some API-calls are normally avoided/used less in OGl due to bad performance and others from DX which are normally eluded with some effort would perform well when their OGl counterpart is used.
Posted on Reply
#21
Aquinus
Resident Wat-man
by: olstyle
As far as I understand from a short look in the source, this wrapper is used at compile-time.
This means that there is no overhead for redirected calls at runtime, but you need the source of a game to make use of it.
I'd still expect a slight performance hit compared to native OGl though. Some API-calls are normally avoided/used less in OGl due to bad performance and others from DX which are normally eluded with some effort would perform well when their OGl counterpart is used.
I saw translated calls and not a whole lot of pre-prossessor directives. I don't think it's done at compile time, but it doesn't do much more than add another reference frame to the call stack as most of those translated calls are pretty simple (direct one-to-one translations with one line of code,), but any extra calls take time to do and I'm sure there are things that DX does faster than OpenGL and things that OpenGL does faster than DX.
Posted on Reply
#22
olstyle
Even a stupid compiler will inline most of those calls and get rid of the added reference, but they are not strictly preprocessor, that's right.
Posted on Reply
Add your own comment