Hacker News Reader

Comment by Geezus_42 | Hacker News Reader

I can't imagine what the nested layers of emulation would do to performance. Lol

I think it has the potential to be pretty good, especially on modern hardware. If using DXVK or VKD3D is any indication, I think the performance losses can be minimized. Plus, I've used Zink before on Mesa's RADV Vulkan driver, and it's pretty good.

But why? Why do we need a thousand layers of emulation?

Someone could write an OpenGL layer directly on Metal. There have been a few incomplete starts at that.

Meanwhile, writing an OpenGL-on-Vulkan layer has been a plan for deprecating/simplifying driver support for OpenGL for quite a while now. Might as well focus efforts on that.

Sounds reasonable.

I believe the purpose of Zink is that if someone is writing a new driver for a new GPU, they only need to write a Vulkan driver. After all, OpenGL is a legacy API. Still has lots of uses. But, I think it's better if the effort to write a new driver is spent on bringing up just a Vulkan implementation instead of needing to write two drivers of once.

It's kind of like how Mesa's existing OpenGL drivers all switched to Gallium3D, which splits the Graphics driver into an agnostic front-end and a device-specific backend. Allows for a lot of re-use and optimization. I heard they're wanting to do something the same with their Vulkan drivers for the future as well.

Makes sense

For Vulkan-on-Metal it shouldn't matter much because in the modern 3D APIs most of the expensive work happens upfront in the 'init path' (e.g. when creating objects, not when using them).

OpenGL on a modern API is another issue though because OpenGL is highly dynamic and really isn't a great match for translating to Vulkan, Metal or D3D12 (e.g. changing OpenGL state may involve throwing away and creating underlying Vk, Metal or D3D state objects on the fly, which is expensive).

Interesting

The hits would come from format transformations. When the math gets to the metal, there is little difference.

It's destroying and creating Vulkan objects (which then in turn destroy and create Metal objects) when changing some random GL state (aka "hash-and-cache") which is the critical problem when trying to emulate GL on a modern 3D API.

Modern 3D APIs have moved all expensive operations into the creation of immutable state-group objects, while OpenGL is the opposite (every single state can be changed at any time).

E.g. mapping any modern 3D API to any other modern 3D API is mostly fine since the expensive operations happen outside the hot path, but mapping OpenGL to any modern 3D API is problematic.

Reply on news.ycombinator.com