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

Better document the intent of instance_extensions and device_extensions in layer manifests #1548

Open
charles-lunarg opened this issue Sep 5, 2024 · 0 comments
Labels
enhancement New feature or request layers

Comments

@charles-lunarg
Copy link
Collaborator

One "device_extensions" node with an array of one or more elements is required if any device extensions are supported by a layer;

One "instance_extensions" node with an array of one or more elements is required if any instance extensions are supported by a layer

Both the instance and device extension lists in the JSON manifests specify that layers should "list their supported extensions" without actually defining what supported means.

A rule of thumb I've used is if the layer "implements" the extension, the manifest should contain the extension. That is, if the underlying driver is missing the extension entirely and no other layers implement the extension, the application would still be able to use the extension. Example: On android, VK_EXT_debug_utils is not implemented by the android loader unlike the desktop loader. When the Validation Layer is enabled, because it implements VK_EXT_debug_utils, applications are now able to use the extension.

This is a rule I've had when looking at the manifest, but it isn't the only interpretation used. A survey of existing layers & their extension lists as well as the entrypoints listed should be conducted to see what kinds of extensions are listed and if any similarities in usage is shown.

Lastly, the loader's usage of these manifest fields should be clearly documented so that layer writers can understand what is expected and what it is used for. Currently, the documentation gives no indication for "why" the fields should be populated at all. And if the loader has no practical purpose for the fields, it may be worth pursuing deprecation of the fields.

@charles-lunarg charles-lunarg added enhancement New feature or request layers labels Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request layers
Projects
None yet
Development

No branches or pull requests

1 participant