Dxvk: [Question/Theoretical] OpenGL Support

[NikoofDeath]

I'm aware that this is out of the scope of the project, this was just the only way of contact I could find. Feel free to close the issue right away, and apologies for the roundabout form of contact.

As someone who has a fringe DXVK use case (Using on Windows to mitigate AMD driver overhead), I am curious why, with DXVK so far advanced, there is no similar project for wrapping OpenGL to Vulkan in a usable state for retail games? I am aware of Zink, VKGL, and GLOVE as projects working on this, but none are close to the progress DXVK has.

Is it simply a lack of interest (since the primary use case for DXVK, wrapping to vk for use on linux, would either have far less benefits for gl to vk, or none at all)? Or is there something that makes wrapping d3d to vk easier/less complicated than gl to vk (as someone with limited knowledge on the matter, my assumption has been that, given Vulkan is derived from OGL, it would be much easier to wrap ogl to vk than d3d to vk)?

I mainly ask because, for my fringe use case, the potential benefits of avoiding AMD's windows ogl drivers are far greater, due to those drivers being particularly problematic.
Again, apologies for the frivolous issue, was just hoping for some insight into the topic.

[bno1]

AFAIK this project is sponsored/funded by Valve. Don't quote me on that, I don't know all the details.

[Leopard1907]

I am curious why, with DXVK so far advanced, there is no similar project for wrapping OpenGL to Vulkan in a usable state for retail games?

DXVK's and therefore Proton's main aim is Linux and that platform doesn't have a OGL related perf issue on AMD hardware ( Mesa ) , NV always had a solid OGL implementation on Windows and Linux also.

So that is why such a thing doesn't exists.

[K0bin]

So that is why such a thing doesn't exists.

It does exist, just not as part of DXVK.
https://gitlab.freedesktop.org/kusma/mesa/tree/zink
https://github.com/google/angle (GL ES so far)
https://github.com/Think-Silicon/GLOVE (GL ES so far)
https://github.com/kbiElude/VKGL (appears to be dead)

The problem is that desktop OpenGL with all relevant extensions is probably bigger than all Direct3D versions combined.

[tannisroot]

You can avoid AMD's Windows Drivers by installing Linux and using our cool and nice open source Mesa OGL drivers. 🐸🐸🐸
Most games work fine on Linux anyway, even Windows ones.

[ReinUsesLisp]

Is it simply a lack of interest (since the primary use case for DXVK, wrapping to vk for use on linux, would either have far less benefits for gl to vk, or none at all)? Or is there something that makes wrapping d3d to vk easier/less complicated than gl to vk (as someone with limited knowledge on the matter, my assumption has been that, given Vulkan is derived from OGL, it would be much easier to wrap ogl to vk than d3d to vk)?

As it is today, feature-wise Vulkan is a subset of OpenGL. Including extensions (even if they are not as widely supported on Vulkan as they are in OpenGL) there are several missing features on Vulkan that are widely available on OpenGL implementations, naming some:

• Quads, quad strips, polygon and line loops.
• Arbitrary primitive restarts (mixed up with the primitives mentioned above and u8 indices).
• Arbitrary texture border colors.
• Per face polygon modes.
• GL_CLAMP.
• Texture rectangles.
• Legacy varyings.
• Masked color clears.
• Alpha testing.
• glProvokingVertex.
• Bindless textures (in case the application uses them in uncommon ways).
• glClampColor.
• [-1, 1] NDC. Relatively simple to fix on common cases, it gets complicated when you are maxed out of varyings and gl_Position.z is used in a transform feedback.
• "glBindImageTexture to bind a layer of a 3D texture to a 2D image", described here.

I avoided mentioning vendor extensions and permissive situations (copying depth to color images on Nvidia) and many OpenGL nonsense like glRenderMode. Most of the mentioned examples are supported at a hardware level on some vendors.

[doitsujin]

The primary reason why DXVK does not and will never support OpenGL is that writing an OpenGL driver at this point in time that isn't based on Mesa would be outright insane. At this point it's almost 30 years worth of API design flaws, driver bugs that somehow became the de-facto standard, and broken applications to catch up to. D3D (especially D3D9) is bad enough in that regard, but GL is an absolute nightmare, even Mesa started supporting the compatibility profile (which nobody should be using, but everybody does in fact use) only recently.

All that is in addition to the various compatibility problems mentioned by @ReinUsesLisp. Some of these features are easy to emulate, others really aren't and are also a problem for Zink.

The fact that only now is there even some awareness that AMD broke the API completely in their Windows driver almost a month ago also highlights that there's hardly any real use case for OpenGL on Windows. Some emulators use it (some of which will or have already switched to Vulkan), some professional software that no one would ever use DXVK for anyway, a handful of id Tech games nobody plays anymore, but that's basically it.

I don't know if Zink will ever support Windows, or how hard it would be to port (main issue being WSI since it doesn't use Vulkan swap chains for presentation), but that's the project you should be looking at.

[Joshua-Ashton]

As for some of the missing OpenGL

Arbitrary texture border colors.

We need this feature too -- it's hopefully going to be a thing possibly maybe.

Alpha testing.

Can always just use a push constant for alpha reference + OpKill at the end of a shader like we do in D3D9 for DXVK.

glClampColor

I don't get how this is an issue given Vulkan has no direct equivelant to glReadPixels?

Masked color clears.

Compute shader magic?

Legacy varyings.

Just shove them in some other slot? D3D9 has things like fog factor and stuff for outputs that we just bodge this way.

"glBindImageTexture to bind a layer of a 3D texture to a 2D image", described here.

Interesting, I wasn't aware that was actually illegal in the spec. Sounds like something I would do and not realise it :frog:

We have d3d9.forceSamplerTypeSpecConstants for games that do stupid things like that -- which we do on PS 1.x anyway as samplers are untyped.

[ReinUsesLisp]

glClampColor

I don't get how this is an issue given Vulkan has no direct equivelant to glReadPixels?

As often, it looks like the online OpenGL reference is wrong. I mean this usage of glClampColor.

Masked color clears.

Compute shader magic?

It still breaks render passes :(
I think a better solution is to draw two triangles in the cleared region and pray for the guest software to be good and use the same framebuffer afterwards.

Legacy varyings.

Just shove them in some other slot? D3D9 has things like fog factor and stuff for outputs that we just bodge this way.

Theoretically you can mix them up (generic attributes + legacy varyings), although I haven't tried it out. Not a big issue as you said. I mentioned it since it covers the described criteria.

Alpha testing.

Can always just use a push constant for alpha reference + OpKill at the end of a shader like we do in D3D9 for DXVK.

Granted, I mentioned it because it's a hardware feature on Nvidia and it's not exposed besides GL, D3D9 and proprietary console APIs :frog:

[Joshua-Ashton]

Granted, I mentioned it because it's a hardware feature on Nvidia and it's not exposed besides GL, D3D9 and proprietary console APIs 🐸

I wouldn't be opposed supporting an NV-only ext for D3D9 DXVK for this if there is any worthwhile performance benefit from it.

But I would not expect that to become an EXT ever

[ReinUsesLisp]

Performance would be negligible since you already have to recompile shaders (or push values) for different things (as far as I'm aware of), and this is at most 12 bytes to cache (~5 if it's packed). It'd just be for ease of use, which is already removed for unsupported drivers.

It's a different story if we are talking about caching vertex formats or 8 render targets of blending with advanced operations enabled.

Edit: I don't care about this stuff being vendor-specific either :frog: