Three new problems observed due to recent changes in the Vulkan Samples framework and samples:
- The shader_debugPrintf sample does not show debug position information in the display for release builds. Observed on Windows and macOS, not tested on Linux.
- The sample fails when executing as part of a batch mode run. Observed on macOS.
Problem 1 is due to missing the VK_EXT_layer_settings extension in Release builds (on by default in framework for debug builds). The sample does not request this extension even though it needs to use layer settings to configure the Vulkan Validation Layer. The extension must now be present for the framework to activate layer settings during instance creation.
Problem 2 is due to not clearing the the static enabled_layer_settings vector between successive calls to get_instance_create_info_extensions() prior to calling createInstance(). This means that layer settings from earlier samples in a batch run can persist and pollute later samples in the run. This shows up on macOS due to use of layer settings for configuring MoltenVK, which causes a crash in shader_debugPrintf. While observed on macOS this is a systemic problem that could affect any platform.
Also when looking at the code for problem 2 above, a third problem was found:
- The
DebugUtils and DebugReport default callback setup is reversed in get_instance_create_info_extensions(): DebugReportCallbackCreateInfoEXT is used for DebugUtils and vice versa. This is clearly incorrect and must have resulted from a code editing error.
I will submit a PR to address these three issues.
Three new problems observed due to recent changes in the Vulkan Samples framework and samples:
Problem 1 is due to missing the
VK_EXT_layer_settingsextension in Release builds (on by default in framework for debug builds). The sample does not request this extension even though it needs to use layer settings to configure the Vulkan Validation Layer. The extension must now be present for the framework to activate layer settings during instance creation.Problem 2 is due to not clearing the the static
enabled_layer_settingsvector between successive calls toget_instance_create_info_extensions()prior to callingcreateInstance(). This means that layer settings from earlier samples in a batch run can persist and pollute later samples in the run. This shows up on macOS due to use of layer settings for configuring MoltenVK, which causes a crash in shader_debugPrintf. While observed on macOS this is a systemic problem that could affect any platform.Also when looking at the code for problem 2 above, a third problem was found:
DebugUtilsandDebugReportdefault callback setup is reversed inget_instance_create_info_extensions():DebugReportCallbackCreateInfoEXTis used for DebugUtils and vice versa. This is clearly incorrect and must have resulted from a code editing error.I will submit a PR to address these three issues.