RFC: Which extensions to support?

[tomaka]

For the moment new features are getting added to Vulkan only through the extensions mechanism. Many people were anticipating a version 1.1 of Vulkan with support for virtual reality and multigpu, but in the end all we got was new extensions.
It is still unknown whether we are going to get new versions of Vulkan, or if khronos will continue adding features only through extensions.

Therefore there's an obvious question: which extensions should vulkano support?

Here are my thoughts about this:

• The default for KHR and EXT extensions is that they should be supported unless there's a reason not to.

• The default for vendor-specific extensions (ie. NV, AMD, etc.) is that they shouldn't be supported unless there's a reason to.

• Some extensions like VK_KHR_maintenance1 or VK_KHR_get_physical_device_properties2 should be handled internally by vulkano, as they are basically "administrative" extensions that do not provide any graphics-related feature themselves. However I'm not sure whether the user should have to enable them manually or not.

• KHX extensions (the 'X' stands for "experimental") could be supported, but in a different branch of vulkano while we wait for them to become stable. If however the extension is popular and demanded, let's merge support for it into master.

• Extensions that allow creating a surface from some kind of platform-specific handle (eg. VK_NN_vi_surface) should be supported, as they are very small and very easy to support.

• I'm hesitating about extensions that interface with the operating system (like VK_EXT_acquire_xlib_display, or VK_KHX_external_semaphore_win32 if it becomes stable). It's also a maintenance burden to support several platforms in a robust way.

• Big vendor-specific device extensions (eg. VK_NVX_device_generated_commands) wouldn't be supported, as they are hard to implement and maintain and provide little benefit (few people are going to use features that only work on the hardware of one specific vendor).

• When it comes to small vendor-specific extensions that could be implemented in a cross-platform way, I'm hesitating. For example VK_AMD_rasterization_order allows you to relax the rules of rasterization which makes things faster. Vulkano could easily ignore the flag on platforms that don't support the extensions. But should the extension be manually enabled by the user, or should vulkano enable it automatically? Hard to answer.

• VK_NV_glsl_shader should certainly not be supported. VK_KHR_push_descriptor exists mostly to make it easier to transition from previous APIs, and I'm hesitating to support it as well.

[nicokoch]

However I'm not sure whether the user should have to enable them manually or not.

IMO the default answer to this should always be yes.
Explicitness is one of the main advantages of vulkan over OpenGL, and taking that away from the user is a step in the wrong direction.

However, once i.e. VK_KHR_get_physical_device_properties2 has been activated by the user, vulkano should automatically use the new functions to (for example) query features under the hood.

Thoughts?

[tomaka]

The small problem is dependencies between extensions.

For example VK_KHX_multiview requires VK_KHR_get_physical_device_properties2. What happens if the user enables VK_KHX_multiview but not VK_KHR_get_physical_device_properties2?

I guess the correct answer would be a runtime error that the user must manually solve.

[nicokoch]

In that case, does vulkan throw an error, that vulkano passes to the user? Or is this only true with validation layers enabled? Must vulkano manually check for stuff like that?

[tomaka]

No, Vulkan doesn't check that.
In fact it's not a "hard dependency". It's more "if you want to use VK_KHX_multiview you will need to use VK_KHR_get_physical_device_properties2 as well".

It's similar to swapchains and surfaces for example. The swapchain extension depends on the surface extension, because in order to create a swapchain you need to create a surface first. Although it's probably legal to enable the swapchain extension without the surface extension, in practice it's useless to do so.

But here the situation is a bit different from swapchains and surfaces, because vulkano would use VK_KHR_get_physical_device_properties2 internally instead of exposing its methods.

[nicokoch]

Well, another possibility is creating new interfaces, like PhysicalDevice::features2(), which would use the new functions. This gives the user total control over what's happening, but is not really possible right now since everything is loaded implicitly at instance creation.

[minecrawler]

Well, I think it's important to leave the control with the user. That's one of the strong points of Vulkan and Vulkano should behave as predictable as possible. No features should be activated automatically, as that might lead to trouble in edge cases.

Then how should dependencies be handled? Is see two possible solutions. One: Since the spec is not explicit, don't be explicit either; that's not really user-friendly, though. Two: Do dependency checks. Vulkano would have to maintain a list of extensions and their dependencies and check if all dependencies have been activated as well. If not, an Err should be returned at some point which contains detailed information about which extension was activated and which dependency is missing ("Error: The extension KHR_XYZ was activated even though its dependency KHR_ABC is missing!", ideally as a struct with the extension names in different fields). Since it is possible to activate extensions without their dependencies, Vulkano might feature a whitelist of extensions which should not have dependency checks. That forces the user to be very explicit that they really want to do what they are doing, but helps users tremendously with the default scenario.

Either way, imho Vulkano should automatically make use of any extension which was activated and is fully usable.

[dylanede]

Would it be possible to allow enabling extensions by string name as well, without actually adding API support for the features they add? This would be helpful for interop with external libraries that require certain extensions to be enabled (thinking mainly of Oculus VR and OpenVR here).

[tomaka]

@dylanede That's possible already.

[u2re-dev]

I able, or not, to suggest for add subgroup operations support in Vulkano?

[jpryne]

@dylanede That's possible already.

@tomaka: Where can I read about how to do this?

[malte-v]

I think it would be great if we supported the VK_KHR_external_* family of extensions. That would allow vulkano to interface with other graphics APIs, like OpenGL. It's not trivial to implement though.

[Rua]

In principle Vulkano now supports what it can, but it definitely should prioritise core functions first, then KHR, then EXT, then vendor-specific. In practice that has meant that very few vendor-specific extensions are now supported, but if implementing them doesn't detract from more important things, I don't see why they couldn't be.