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

API subset generation #1611

Open
t-artikov opened this issue Jul 3, 2023 · 1 comment
Open

API subset generation #1611

t-artikov opened this issue Jul 3, 2023 · 1 comment

Comments

@t-artikov
Copy link

While Vulkan (with extensions) contains a vast number of features, usually only a fraction of them are used in a particular project. I suggest adding the ability to specify the API version and a list of extensions for VulkanHppGenerator. For example:
./VulkanHppGenerator -api-version 1.1 -extensions VK_KHR_swapchain,VK_EXT_debug_utils
The resulting header files will only contain the specified functionality.

This offers the following benefits:

  • Reduced compilation time.
  • Improved runtime performance - no need to resolve and store unnecessary function pointers.
  • Enhanced usability - less noise in IDE autocomplete hints.
@asuessenbach
Copy link
Contributor

That's an interesting approach for those who regularly build their vulkan.hpp on their own, instead of just using what's provided by the Vulkan SDK.
Of course, when specifying an api-version, all versions up to that version would be generated.
And when specifying an extension, all extensions (and potentially versions) that extension depends on would be generated as well.

But I think, this would be approached with low priority:

  • On reduced compilation time: this is probably a non-issue when you're using C++20-modules, which is supported by Vulkan-Hpp now.
  • On improved runtime performance: I doubt that this is worth such an effort. It would reduce the number of functions to resolve and store by a few dozens. Resolving is done once or twice on start-up, and a few dozen function pointers is not that much memory to gain.
  • On enhanced usability: agreed, that could be real benefit.

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

No branches or pull requests

2 participants