search

KhronosGroup / Vulkan-ValidationLayers

Vulkan Validation Layers (VVL)
https://vulkan.lunarg.com/doc/sdk/latest/linux/khronos_validation_layer.html
Other
748 stars 400 forks source link

gpu: Add experimental non-conditional injection #8259

Closed spencer-lunarg closed 2 months ago

spencer-lunarg commented 2 months ago

2nd attempt at https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/8170

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build queued with queue ID 214665.

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build queued with queue ID 214676.

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build # 17030 running.

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build # 17030 failed.

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build queued with queue ID 214847.

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build # 17034 running.

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build # 17034 passed.

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build queued with queue ID 214907.

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build # 17036 running.

ci-tester-lunarg commented 2 months ago

CI Vulkan-ValidationLayers build # 17036 passed.

spencer-lunarg commented 2 months ago

I see uint32_t being used everywhere, even though the underlying meaning can differ, leading to potentially mixing apples and oranges... Have you considered creating dedicated types to avoid that?

we use to do this (I think SPIRV-Tools did also), it honestly was more annoying then helpful ... basically while it looks like you would mix it up, not once in my 3 years touching SPIR-V can I recall having a bug because I thought this random non-SPIRV thing was actually a SPIR-V id