Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor instance extension and layer handling #1256

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

asuessenbach
Copy link
Contributor

Description

Refactors the instance extension and layer handling.
Simplifies getting the "optimal" set of validation layers by just using VK_LAYER_KHRONOS_validation, assuming this is everywhere available nowadays.
Essentially is a different approach to #780 and would replace that PR.

Build tested on Win10 with VS2022. Run tested on Win10 with NVidia GPU.

General Checklist:

Please ensure the following points are checked:

  • My code follows the coding style
  • I have reviewed file licenses
  • I have commented any added functions (in line with Doxygen)
  • I have commented any code that could be hard to understand
  • My changes do not add any new compiler warnings
  • My changes do not add any new validation layer errors or warnings
  • I have used existing framework/helper functions where possible
  • My changes do not add any regressions
  • I have tested every sample to ensure everything runs correctly
  • This PR describes the scope and expected impact of the changes I am making

Note: The Samples CI runs a number of checks including:

  • I have updated the header Copyright to reflect the current year (CI build will fail if Copyright is out of date)
  • My changes build on Windows, Linux, macOS and Android. Otherwise I have documented any exceptions

If this PR contains framework changes:

  • I did a full batch run using the batch command line argument to make sure all samples still work properly

Sample Checklist

If your PR contains a new or modified sample, these further checks must be carried out in addition to the General Checklist:

  • I have tested the sample on at least one compliant Vulkan implementation
  • If the sample is vendor-specific, I have tagged it appropriately
  • I have stated on what implementation the sample has been tested so that others can test on different implementations and platforms
  • Any dependent assets have been merged and published in downstream modules
  • For new samples, I have added a paragraph with a summary to the appropriate chapter in the readme of the folder that the sample belongs to e.g. api samples readme
  • For new samples, I have added a tutorial README.md file to guide users through what they need to know to implement code using this feature. For example, see conditional_rendering
  • For new samples, I have added a link to the Antora navigation so that the sample will be listed at the Vulkan documentation site

@asuessenbach asuessenbach requested review from gpx1000 and a team January 13, 2025 10:53
@SaschaWillems
Copy link
Collaborator

Not sure on this. It does work, but introduces a fundamental behavior change:

You can no longer run samples if the validation layers are not installed. If the requested layers are not found, an exception is thrown and the sample exits.

On main (before this change), you only get a debug message telling that the layer is not available, but the sample continues to run.

@asuessenbach
Copy link
Contributor Author

@SaschaWillems With what sample do you get that exception?
I would expect to just get some informational output (-> instance.cpp, line 159, for example).

@SaschaWillems
Copy link
Collaborator

Sorry, should've mentioned that. Tested wit the hello triangle sample, and with this PR it throws an exception when it can't find the validation layers and then crashes for me.

@asuessenbach
Copy link
Contributor Author

I see...
Before, the call to vkb::get_optimal_validation_layers returned a list of supported layers. Maybe some older layers, or even an empty list. And that list is checked again right after that.
I will simplify that a bit, assuming nowadays you just want VK_LAYER_KHRONOS_validation or nothing.

Copy link
Collaborator

@SaschaWillems SaschaWillems left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the change. The samples that did their own validation layer checking now also work properly 👍🏻

@gpx1000
Copy link
Collaborator

gpx1000 commented Jan 27, 2025

Thanks for the PR. I have a question. Does this architecture handle optional extensions? (i.e. if an extension exists enable it, if it doesn't still allow for the sample to continue but report that the extension isn't enabled?). #780 seeks to handle the use case of allowing for optional extensions.

@asuessenbach
Copy link
Contributor Author

Does this architecture handle optional extensions?

Yes it does, as you can see for example in instance.cpp, lines 222-238:

	for (auto requested_extension : requested_extensions)
	{
		auto const &extension_name        = requested_extension.first;
		auto        extension_is_optional = requested_extension.second;
		if (!enable_extension(extension_name, available_instance_extensions, enabled_extensions))
		{
			if (extension_is_optional)
			{
				LOGW("Optional instance extension {} not available, some features may be disabled", extension_name);
			}
			else
			{
				LOGE("Required instance extension {} not available, cannot run", extension_name);
				throw std::runtime_error("Required instance extensions are missing.");
			}
		}
	}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants