andy-thomason / Vookoo

A set of utilities for taking the pain out of Vulkan in header only modern C++
MIT License
522 stars 52 forks source link

uniform example (example 03) causes Vulkan layer to report problem. #22

Open FunMiles opened 4 years ago

FunMiles commented 4 years ago

As I was putting the gflw source code in external directory, I ran the examples and got the following error for each frame drawn in the uniform example:

00000008 debugCallback: [ VUID-vkCmdPipelineBarrier-dstAccessMask-02816 ] Object: 0x7fe2c3a63928 (Type = 6) | vkCmdPipelineBarrier(): pBufferMemBarriers[0].dstAccessMask (0x20) is not supported by dstStageMask (0x1). The Vulkan spec states: The dstAccessMask member of each element of pMemoryBarriers must only include access flags that are supported by one or more of the pipeline stages in dstStageMask, as specified in the table of supported access types (https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VUID-vkCmdPipelineBarrier-dstAccessMask-02816)

lhog commented 4 years ago

Seems like validation layer is unhappy about vk::AccessFlagBits::eShaderRead at https://github.com/andy-thomason/Vookoo/blob/master/examples/uniforms/uniforms.cpp#L157

Locally I replaced the enum above with {} as per spec recommendation. Smoke test was successful, but changes like this require some insights from Andy

P.S. Other examples have similar warnings too.

andy-thomason commented 4 years ago

I always defer to the validation layer if possible. It has been a good friend along the way.

On Mon, Apr 6, 2020 at 10:12 PM lhog notifications@github.com wrote:

Seems like validation layer is unhappy about vk::AccessFlagBits::eShaderRead at https://github.com/andy-thomason/Vookoo/blob/master/examples/uniforms/uniforms.cpp#L157

Locally I replaced the enum above with {} as per spec recommendation. Smoke test was successful, but changes like this require some insights from Andy

P.S. Other examples have similar warnings too.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/andy-thomason/Vookoo/issues/22#issuecomment-610039499, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL36XFWNAMBWUQFMPVJD23RLJAVLANCNFSM4MCKGLAA .

FunMiles commented 4 years ago

@lhog , you want to create a PR with your fixes for this?

lhog commented 4 years ago

Technically I can do that, however I wanted to first refresh the barriers topic a little bit to make sure we don't just shut up the validation layer, but do the right thing.

lhog commented 4 years ago

I've started looking into this based on Sascha's examples, but it will take some time. Uniform example should be easy to fix alone, but I think https://github.com/andy-thomason/Vookoo/blob/master/include/vku/vku.hpp#L1489-L1545 might need a fresh look.

andy-thomason commented 4 years ago

I'm anxious to keep this as simple as possible. I don't know which version of Vulkan this changed at. Sasha arrived at permutation hell, so best not to make an N^2 table.

The example here probably should use VK_ACCESS_UNIFORM_READ_BIT instead of the shader read bit. In reality this is unlikely to be an issue. And also the barrier is only really significant between queues as far as I read it (also a bit vague). In this case the write and read are in the same queue and are likely to sync naturally.

Andy.

On Wed, Apr 8, 2020 at 1:01 PM lhog notifications@github.com wrote:

I've started looking into this based on Sascha's examples, but it will take some time. Uniform example should be easy to fix alone, but I think https://github.com/andy-thomason/Vookoo/blob/master/include/vku/vku.hpp#L1489-L1545 might need a fresh look.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andy-thomason/Vookoo/issues/22#issuecomment-610917339, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL36XBTZXOTW5EI2NV5HZLRLRRR7ANCNFSM4MCKGLAA .

FunMiles commented 4 years ago

If I may, a little detour: reading the linked code reminded me of another issue I've left out. Clang complains about a few switch/case where not all cases are handled. Adding a default would silence the compiler warnings but I'm not sure if that's really advisable unless one can guarantee that all other cases should behave as default. Any thoughts, Andy? It's not urgent, but I like my compiler to not give me warnings I ignore as it can make me miss important warnings on my new code.

andy-thomason commented 4 years ago

From my excursions in the rust world, I now appreciate that all the enums must be covered.

You are certainly not OCD about this - or at least you are in good company if you are!

Andy.

On Wed, Apr 8, 2020 at 4:20 PM FunMiles notifications@github.com wrote:

If I may, a little detour: reading the Sasha example reminded me of another issue I've left out. Clang complains about a few switch/case where not all cases are handled. Adding a default would silence the compiler warnings but I'm not sure if that's really advisable unless one can guarantee that all other cases should behave as default. Any thoughts, Andy? It's not urgent, but I like my compiler to not give me warnings I ignore as it can make me miss important warnings on my new code.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/andy-thomason/Vookoo/issues/22#issuecomment-611021059, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL36XECLQS4VNLPJ62MOFTRLSI35ANCNFSM4MCKGLAA .