Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

A very interesting use of open source in action here from the incredibly smart team over at Collabora who teamed up with Microsoft engineers to get OpenGL and OpenCL via DirectX.

Why is this interesting? Well, they're doing it by using the open source Mesa drivers. It's pretty darn clever, and shows just how far translation layers are being used industry-wide. Once this is all implemented, it means that any device that supports DirectX 12 would also work with (and actually be compliant) with OpenGL 3.3 and OpenCL 1.2.

Not all Windows-powered devices have consistent support for hardware-accelerated OpenCL and OpenGL. So in order to improve application compatibility, we are building a generic solution to the problem. This means that a GPU vendor only has to implement a D3D12 driver for their hardware in order to support all three APIs.

This mapping layer is also expected to serve as a starting point in porting older OpenCL and OpenGL applications over to D3D12.

In addition, we believe this is good for the wider open source community. A lot of the problems we are solving here are shared with other drivers and translation layers, and we hope that the code will be useful beyond the use cases listed above.

Collabora

It's not finished yet, plenty of work is still to be done but you can find the source code online now and they are planning to upstream the work to the main Mesa project.

Speaking to Collabora today over email to get something cleared up, I asked them if this actually meant that if a developer made an OpenGL game, that on Windows they could keep it as OpenGL but it would run through DirectX 12 in the driver without the developer needing to do anything. Daniel Stone, Graphics Lead at Collabora, replied to say "Provided the application uses a supported version of the OpenGL API, it will be able to run unmodified using the OS's DirectX 12 driver. This applies to any application, not just games! :)".

What's interesting here then, is not how this directly benefits Linux/Linux Gaming but cross-platform compatibility as a whole which is great. Especially good when it's using open source already, so improvements can go back into upstream Mesa, therefore making Linux drivers even better in future.

I'm keen for anything open source like this that can help developers, good stuff.

See the full blog post on the Collabora website.

Article taken from GamingOnLinux.com.
20 Likes, Who?
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG, Humble Store and Paradox Interactive. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
19 comments
Page: 1/2»
  Go to:

mirv 24 Mar
View PC info
  • Supporter Plus
Well that's...interesting. Microsoft. OpenGL.

Huh.

I would imagine the drive for this is aging software that they can't support anymore. My first thought was CAD software, but then they might use IHV extensions that aren't going to be provided here. Maybe this is just a general backwards compatibility thing, which Microsoft actually do try for, and can help the hardware companies clean up their drivers a bit.

But oh the irony of _Microsoft_ relying on open source software.
Alm888 24 Mar
Well, it might technically be beneficial for Microsoft®, considering Windows' current sore state of built-in OpenGL implementation (I think it is something like "OpenGL 1.1") and could make some vendor-locked-in devices (like "Microsoft Surface") to be somewhat useful. Or to help AMDGPU-powered devices to s**k a little less in OpenGL applications (it would be nice to have a comparison to official AMD OpenGL stack)…

But, honestly, using "DirectX 12" is like betting on a dead horse. I mean, who needs DX12 when we have Vulkan? On the other hand, DX12 is all Microsoft® has, so they are out of options… :S:
Shmerl 24 Mar
Nice and all, but MS are just trying to hide the elephant in the room. They should be supporting Vulkan to begin with, instead of DX12. There is no valid reason for them not to.

So I don't buy all this "we are good now" act, until we'll see Vulkan support on Xbox and any other devices that MS tightly control.


Last edited by Shmerl on 24 March 2020 at 5:24 pm UTC
I may be completely wrong here, but would this part:
QuoteThis means that a GPU vendor only has to implement a D3D12 driver for their hardware in order to support all three APIs.
not be a really bad thing?
Liam Dawe 24 Mar
Quoting: SchattenspiegelI may be completely wrong here, but would this part:
QuoteThis means that a GPU vendor only has to implement a D3D12 driver for their hardware in order to support all three APIs.
not be a really bad thing?
Nope, it helps prevent the Apple situation with OpenGL seeing total crap support for a very long time and eventually they will remove it as it's deprecated in favour of Metal which screwed over a lot of developers.
Leopard 24 Mar
Quoting: Liam Dawe
Quoting: SchattenspiegelI may be completely wrong here, but would this part:
QuoteThis means that a GPU vendor only has to implement a D3D12 driver for their hardware in order to support all three APIs.
not be a really bad thing?
Nope, it helps prevent the Apple situation with OpenGL seeing total crap support for a very long time and eventually they will remove it as it's deprecated in favour of Metal which screwed over a lot of developers.

No , MS won't break compatibility ever which is why they lead consumer market. Even there are some odd examples ; your 10 year old games will still work on newest Windows.

But i doubt implementing OGL over D3D is a good thing at all. Because what MS tries to achieve with it is forcing hw vendors to put all weight on D3D12 drivers but nothing else. So in the end ; OGL apps that relies on it can work but in a very poor state. So that might be another " See , other api's suck. While DX12 Ultimate shines all above them." because they're used to do such marketing.

They did on Vista days anyway which kinda sped up death of OGL usage on modern apps.
Liam Dawe 24 Mar
Quoting: LeopardBut i doubt implementing OGL over D3D is a good thing at all. Because what MS tries to achieve with it is forcing hw vendors to put all weight on D3D12 drivers but nothing else. So in the end ; OGL apps that relies on it can work but in a very poor state. So that might be another " See , other api's suck. While DX12 Ultimate shines all above them." because they're used to do such marketing.

They did on Vista days anyway which kinda sped up death of OGL usage on modern apps.
I get what you're saying, however, with it relying on Mesa unless Microsoft go entirely out of their way to break it by drastically changing DX12 (which they can't, as it would break anything shipping DX12) - it will keep on working. That's the point of this. It uses open source, which can continue to improve and Windows gets decent OpenGL support which does help cross-compatibility.
Leopard 24 Mar
No , actually Windows at this point has nothing to do with OGL situation on Windows.

Reason why OGL is still a relevant api these days ( for professional use cases like CAD apps etc ) is Nvidia and Nvidia's OGL driver is pretty solid on both platforms.

OGL on D3D won't be featureful like NV driver or even AMD's very slow OGL driver,which i don't even take account of many many OGL driver app profiles goes for somewhat broken but important apps. So i think that is not so beneficial as it might seem. There are vendors who can deliver solid OGL implementations already. If they somehow join into this trend and starts to abandon OGL driver of theirs , this might give D3D12 a critical edge over Vulkan , which fears me most.

https://twitter.com/_Humus_/status/1018846492273119233?s=19

Funny story about how AMD screwed with their OGL driver btw.
mirv 24 Mar
View PC info
  • Supporter Plus
Quoting: LeopardNo , actually Windows at this point has nothing to do with OGL situation on Windows.

Reason why OGL is still a relevant api these days ( for professional use cases like CAD apps etc ) is Nvidia and Nvidia's OGL driver is pretty solid on both platforms.

OGL on D3D won't be featureful like NV driver or even AMD's very slow OGL driver,which i don't even take account of many many OGL driver app profiles goes for somewhat broken but important apps. So i think that is not so beneficial as it might seem. There are vendors who can deliver solid OGL implementations already. If they somehow join into this trend and starts to abandon OGL driver of theirs , this might give D3D12 a critical edge over Vulkan , which fears me most.

https://twitter.com/_Humus_/status/1018846492273119233?s=19

Funny story about how AMD screwed with their OGL driver btw.

AMD poured a lot of effort into ATi's drivers actually, and were probably the minds behind trying to unify the Windows and Linux GL drivers. Those decisions are not taken lightly, or without understanding the risks.

And don't worry, Vulkan dominates (or is trending that way) in the mobile space. Microsoft can't touch that, and it's a big space. Then don't forget that perhaps some of this work might encourage OpenGL on Vulkan, simplifying the GNU/Linux driver space. If nothing else, it might get others thinking about it.

Not that I trust Microsoft with this one tiny bit however. They've done their best to deserve such ire.


Last edited by mirv on 24 March 2020 at 6:43 pm UTC
Kudos to Colabora, only
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.