OpenGL Overload: Implementing OpenGL Over Vulkan

[DebianLinuxero]

It reminds me the times of 3dfx and glide.

The OpenGL implementation of Voodoo cards was a layer on top of glide. On both Windows and Linux.

[c117152]

Why? What's the point? Why not just use OpenGL normally?

1. On most mobile\embedded, there's only GLES. In the near future, there will only be Vulkan.
2. On modern desktop\server, Vulkan represents the hardware better then OpenGL.

Put together, you can remove a huge chunk of hardware-dependent code from everyone's drivers by moving all the legacy OpenGL stuff to user-land libraries without performance loses. You can also make sure the full OpenGL is also available for mobile drivers that way.

Overall, this is a REALLY good idea.

[Nille]

You mean on AMD or nVidia, because as far as I know Intel driver does not use Gallium3D, so any Vulkan-based Gallium3D replacement would not work with Intel drivers.

You get it wrong. And for this not the Hardware specific part is required. Its Like Mesa on Vulkan instead of Mesa on LLVM or Mesa on Gallium3D. So it does not depend on Gallium or any other Hardware Implementation.

[zxy_thf]

As was mentioned earlier, this will theoretically be targeted at multiple back-ends as well. So you might be able to use this to eventually run higher GL levels on Macs using the Metal back-end (since they don't support Vulkan yet). It's an interesting idea, at least, and may make it easier for the driver developers to shift from having to implement both GL and Vulkan to just supporting Vulkan at some point in the future (which could be less intensive in development hours for them).

Using mesa doesn't mean you can't use Metal. It only implies you may need port something to macOS, but this also holds for developing from scratch.

[zxy_thf]

It's obviously intended to be used by more than linux on AMD/intel

Probably you misunderstand something.
Reusing mesa only means reusing the code from GL dispatching till pipe driver, and all you need is to write a Gallium driver which implements everything over Vulkan/Metal/DX12 instead of upon actual hardware. This implies you already have a well-tested OpenGL state tracker.

[darkbasic]

someone should tell him to open the issues on his repo, since he says in the README to file issues. I can't find an obvious email address for him, and I don't twit.

[email protected]

[funfunctor]

What a complete wast of time. DX12 on top of Vulkan as a library sounds far more doable and pragmatic. OGL on top of Vulkan, ridiculous.

[pracedru]

This makes a lot of sense actually.. for future drivers and hardware, there would be a lot of time and effort saved.
I think that people don't see the usefulness from a user's point of view. And that is correct. But what people might not realize is that this could mean faster, better and cheaper hardware support in the future.

[geearf]

someone should tell him to open the issues on his repo, since he says in the README to file issues. I can't find an obvious email address for him, and I don't twit.

The issue tracker is open now.

[theriddick]

Yeah I would agree with others, having DX11/DX12 running through Vulkan would be much more useful for developers whom want to port it to other platforms since that covers 99.9% of games right there. But I guess there are other issues in that regard since DirectX is a FULL suite and not just a graphics API...