Vulkan-ValidationLayers VS Vulkan-Docs

If this works then it might actually be a game bug and the game I guess passes invalid shaders when the cache exists... but it seems to work fine on windows vulkan drivers. You could try to run the game with https://github.com/KhronosGroup/Vulkan-ValidationLayers

For debugging these kinds of issues, I would recommend enabling the synchronization validation layer.

I would use the debugger to produce a stack trace and look into the validation layers source code. https://github.com/KhronosGroup/Vulkan-ValidationLayers Then I would either file an issue or make a PR there.

Currently validation layers might generate false-positive errors: https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/3450

A'rightey... I was able to reproduce this issue with Sascha Willems basic triangle example, so I am fairly certain, that this is a bug. I've opened an issue.

I am really at loss here, I found this issue but it doesn't really help me (I am starting to doubt it's even possible, maybe I'm a clown and doing it wrong...)

Can you post a reproduction case at https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues so we can take a look at it.

Which is why a GPU debugger with frame tracing is so much better option.

By the way, there are actually ways to expose a print function on shader code, provided there is driver support.

https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob...

Huh yeah. Looking through the header the function you want works with c but there are others using c++ features. The reason given is understandable.

Pipelines (or in general terms PSOs) are the most problematic aspect of Vulkan / DX12 - much more than synchronization! Large parts of the gamedev industry seems to recognize all the performance issues with pipelines and therefore companies are experimenting with newer models like the VK_EXT_shader_object extension ("Vulkan without Pipelines": https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...).

I've written a detailed comment about this before here (https://news.ycombinator.com/item?id=37843946#37845431) but for a much more comprehensive explanation by an engineer from Nintendo read the initial proposal for the VK_EXT_shader_object extension: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/propos...).

There's also Casey Muratori's mail to the Vulkan advisory on 2015 that basically predicts this whole clusterfuck would happen: https://github.com/cmuratori/misc/blob/main/vulkan_dynamic_s...

Apple -> MoltenVK is an emulation layer and doesn't give you as much control as using Metal directly.

Nintendo and Sony prefer their own APIs, NVN and LibGNM, and AIUI Vulkan is a second-class API on those platforms which does not offer as much power, it is widely understood studios use NVN and LibGNM to get access to the real hardware on those platforms.

Windows/AMD/NVidia/Intel -> HW manufacturers tend to prototype and release new features with D3D first and then 'backport' them to Vulkan after a while. DirectX 12 for example had mesh shaders for over 2 years before Vulkan got a vendor neutral extension for them[0]

Android and Linux are the only platform where Vulkan is a first-class citizen.

You could maybe argue Nvidia treats Vulkan as a first-class citizen because they tend to have vendor-specific Vulkan extensions for the latest features available before anyone else. But otherwise, no, Vulkan is not a first-class API anywhere except Linux and Android.

Graphics API wars are alive and well.

[0] https://github.com/KhronosGroup/Vulkan-Docs/issues/1423