3 ms·

I have no exp in this area but wouldnt we loose a lot of performance by having two shims. Application -> OpenGL -> Zinc -> Vulkan -> MoltenVK -> Metal -> Hardw

• bumblebritches5 4y ago
• uluyol 4y ago
  Not necessarily, especially when you factor in limited (human) resources in. Zink has outperformed native GL drivers even though it introduces an extra layer through vulkan. Ideal world, we'd have direct GL to metal or hardware, but implementing a GL driver is a big effort.
  • samus 4y ago
    Especially since a lot of work has been put into Zink already. Zink is basically the general case of migrating an OpenGL game engine to a lower-level Vulkan-style API.
  • badsectoracula 4y ago
    > Zink has outperformed native GL drivers even though it introduces an extra layer through vulkan. That is not the case here (Radeon RX 5700 XT, Linux), Zink is consistently slower than the "native" OpenGL. A quick test with Dhewm3 ("modernized" version of the Doom 3 engine) has the native driver running 1.5 times faster than Zink and with an engine of mine the native driver is ~4 times faster. I don't have many games to benchmark on but in general Zink tends to be slower than a native driver, but depending on the hardware and game the difference might not be noticeable in practice (without an FPS counter). In the future when hardware is faster than today it might not make much of a practical difference even in benchmarks.
• samus 4y ago
  The mapping of Vulkan to Metal should be fairly direct and efficient, since the architecture of these APIs is very similar. The question is whether there are any important edge cases or bugs that need addressing, or whether the Zink + MoltenVK combination is just missing some optimization work.