User-configurable gpuav indices_count#11581
User-configurable gpuav indices_count#11581spencer-lunarg merged 2 commits intoKhronosGroup:mainfrom
Conversation
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
|
I'm not against this, I need to look into this first more, I know we have a
so 64k is an actual hard limit without more thinking We have something similar with DebugPrintf where we give a warning and how to up the limit message << "[WARNING] Debug Printf message was truncated due to the buffer size ("
<< gpuav.gpuav_settings.debug_printf_buffer_size << ") being too small for the messages consuming "
<< output_buffer_dwords_counts
<< " bytes.\nThis can be adjusted setting env var VK_LAYER_PRINTF_BUFFER_SIZE=" << output_buffer_dwords_counts
<< " or in vkconfig";I'll leave comments, but one thing we will 100% need is a test that does over 8k draws and sets this new setting to ensure it is working (see |
| const char *VK_LAYER_GPUAV_DEBUG_DUMP_INSTRUMENTED_SHADERS = "gpuav_debug_dump_instrumented_shaders"; | ||
| const char *VK_LAYER_GPUAV_DEBUG_MAX_INSTRUMENTATIONS_COUNT = "gpuav_debug_max_instrumentations_count"; | ||
| const char *VK_LAYER_GPUAV_DEBUG_PRINT_INSTRUMENTATION_INFO = "gpuav_debug_print_instrumentation_info"; | ||
| const char *VK_LAYER_GPUAV_INDICES_COUNT = "gpuav_indices_count"; |
There was a problem hiding this comment.
| const char *VK_LAYER_GPUAV_INDICES_COUNT = "gpuav_indices_count"; | |
| const char *VK_LAYER_GPUAV_MAX_INDICES_COUNT = "gpuav_max_indices_count"; |
lets go with max_ here now we are making it public facing
also move it above, away from, the DEBUG_ settings
| gpuav_settings.debug_print_instrumentation_info); | ||
| } | ||
|
|
||
| if (vkuHasLayerSetting(layer_setting_set, VK_LAYER_GPUAV_INDICES_COUNT)) { |
There was a problem hiding this comment.
100% not obvious, but this is all generated/handled by having it in the VkLayer_khronos_validation.json.in file, so will need to add it there
then run python3 scripts/generate_settings.py to generate the logic needded
There was a problem hiding this comment.
Are you sure? I'm running that script and layer_options.cpp doesn't change. Also the only occurances of "vkuHasLayerSetting" are in this file, i would expect it to be present as string somewhere in the generation scripts.
|
@MennoVink also feel free to reach out to me via the Khronos Discord/Slack (or email) if you want to discuss this more offline |
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
CI Vulkan-ValidationLayers build queued with queue ID 637900. |
|
CI Vulkan-ValidationLayers build # 22337 running. |
|
CI Vulkan-ValidationLayers build # 22337 passed. |
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
I've added the new setting to VkLayer_khronos_validation.json.in. I gave it the range minimum of 0 to turn it into an unsigned integer. Giving it a max of 65535 is not how i'm supposed to limit against kActionId_Mask i'm assuming? I dont see a bounds check appearing when i build vvl_codegen. I've added test NegativeGpuAVDescriptorIndexing::MaxDispatchCount, but i need some help here. Most importantly with solving it still failing intermittently. I dont quite understand yet how the layer's queue system works, but my hunch is that i have to wait for queue retirements? These overflow errors are generated asynchronously so might not have fired yet. A thread sleep doesn't seem to help though so maybe it's another issue. |
This can be used by apps using large amounts of draw commands to not run into the internal limit.
|
Author MennoVink not on autobuild list. Waiting for curator authorization before starting CI build. |
|
@MennoVink so first off, thanks again for this PR I made some tweaks and pushed up a new commit on your branch, but this looks good to go!
yes, 100% no obvious, added a warning/check/test for that
yep agree, removed that requirement from the json
So we actually have a few tests already that are checking when the limit is hit (they are done in a way to not bring down the CI machine when we inject invalid behavior by using the Robustness checks) what I wanted (and I just modified it) was I wrote a test where it we set Also I realize how non-obvious if you set the max to |
|
CI Vulkan-ValidationLayers build queued with queue ID 641245. |
|
CI Vulkan-ValidationLayers build # 22373 running. |
|
CI Vulkan-ValidationLayers build # 22373 passed. |
4 participants
This can be used by apps using large amounts of draw commands to not run into the internal limit.
I have a test app that happens to end up using 8194 draw commands. The validation layers output an error because it's running into the internal invalid_index_command limit of 8191.
What else would be needed to get something like this through if at all?
I'm assuming documentation if this should be a public setting.
What do you think about the order in layer_options, i've added it as last, but now it's with DEBUG options, i'm not sure what the naming convention is here and how they should be grouped.