Mateusz Kielan

Source is here btw: https://github.com/Devsh-Graphics-Programming/Nabla-Examples-and-Tests/blob/master/07_StagingAndMultipleQueues/main.cpp

This code change silences the validation layer (if I treat every GPU as I'd treat Intel): https://github.com/Devsh-Graphics-Programming/Nabla-Examples-and-Tests/commit/4e48f0b27213fae6ce032bae4ff2ff0622921afc Basially my code is a repro for validation layers choking on timeline semaphores...

Funny thing, renderdoc chokes on this usage as well, but it actually freezes up completely. I guess its because its not been coded to be able to defer a capture...

I'm getting a new validation error message afdter upgrading the SDK from 265 to 275 ``` [14.03.2024 16:40:02:505453][ERROR]: Validation Error: [ VUID-VkImageCreateInfo-imageCreateMaxMipLevels-02251 ] | MessageID = 0xbebcae79 | vkCreateImage(): pCreateInfo...

> @devshgraphicsprogramming yes we currently call `vkGetPhysicalDeviceImageFormatProperties2` for you (with all the pNext passed in as well) > > > that kind thats supposed to be supported on every GPU...

yep that worked.

Is concurrent sharing of the resource a solution to still getting useful syncval and no false errors then?

How can I silence that particular validation error?

we will likely be sleeping for anything between 50us and 33ms, can you make win32, linux and wasm benchmarks for this and figure out the us amount of sleep when...

Btw it works for non-array types https://godbolt.org/z/9G7vnhesr and on this simple repro https://godbolt.org/z/ze8jaoM3z But this is a full explicit specialization out of line initialization, not a partial.