<p>Extensions can change the visible behavior of the implementation, not to mention the implementation of it.</p>

<p>Consider KHR_external_semaphore and its various sub-extensions. If you don't specify them, then the <code>VkDevice</code>'s implementation knows that you're not going to need to be able to turn a VkSemaphore into an externally-accessible mutex and back. So the implementation may be able to use a more efficient <code>VkSemaphore</code> implementation.</p>

<p>If the extension is always on, the device <em>must</em> assume that you're going to use it. And thus, any possible efficiency is lost.</p>

<blockquote>
  <p>wouldn't it be easier to just create one VkInstance and one VkDevice with everything enabled?</p>
</blockquote>

<p>How? If you have two <code>VkDevice</code>s, unless they are both attached to the same <code>VkPhysicalDevice</code>, there's no guarantee that "everything" is the same thing for both devices.</p>

<hr>

<p>Cross-process Vulkan interop is <em>not</em> something external code is expected to define. There are extensions that provide various aspects of such interop.</p>

CC BY-SA 3.0
2018-02-21T17:10:22.483Z
To clarify: When I mentioned “cross-program”, I was referring to for example an executable calling into a third-party library from the same thread, rather than anything like cross-process interop. But it may fit the same ballpark regardless.
haasn
CC BY-SA 3.0
2018-02-21T17:38:49.297Z
@haasn: In that case, the client third-party library and the calling layer should both agree on such things. That is, as part of the client library's documentation, it says "you must have enabled extensions/features X, Y, Z" or it has a way to inform you of what extensions/features are enabled.
Nicol Bolas
CC BY-SA 3.0
2018-02-21T16:33:23.330Z
2018-02-21T16:33:23.330Z
Nicol Bolas
<p>This is sort of an API design question. Why do vulkan instance/device extensions need to be specifically enabled, in order for their calls to be available?</p>

<p>Wouldn't it make more sense to have extensions just always “be there” if they're supported in this environment, and then the API user can query which ones are actually available after device creation?</p>

<p>Another way of phrasing this question might be: Is there any reason <em>not</em> to enable every supported extension when creating a vulkan instance/device?</p>

<p>The reason I'm asking is because I'm specifically worried about vulkan interop between multiple programs. The fact that each program's VkDevice is distinct means you can't just straight up share VkImages. But agreeing on a common VkDevice is tricky because they may have different extensions/features enabled, so the interop API must account for the fact that both users may provide a set of extensions that they want enabled on the resulting VkDevice. This seems needlessly complex - wouldn't it be easier to just create one VkInstance and one VkDevice with everything enabled?</p>

<vulkan><api>
Why do vulkan extensions need to be enabled?
haasn
# Why do vulkan extensions need to be enabled?

(Asked by: username_0 on 2018-02-21)

This is sort of an API design question. Why do vulkan instance/device extensions need to be specifically enabled, in order for their calls to be available?

Wouldn't it make more sense to have extensions just always “be there” if they're supported in this environment, and then the API user can query which ones are actually available after device creation?

Another way of phrasing this question might be: Is there any reason *not* to enable every supported extension when creating a vulkan instance/device?

The reason I'm asking is because I'm specifically worried about vulkan interop between multiple programs. The fact that each program's VkDevice is distinct means you can't just straight up share VkImages. But agreeing on a common VkDevice is tricky because they may have different extensions/features enabled, so the interop API must account for the fact that both users may provide a set of extensions that they want enabled on the resulting VkDevice. This seems needlessly complex - wouldn't it be easier to just create one VkInstance and one VkDevice with everything enabled?

**Tags:** vulkan, api


---

## 1 answers

### Answer by username_1 on 2018-02-21. Score: 1 | Accepted answer

Extensions can change the visible behavior of the implementation, not to mention the implementation of it.

Consider KHR\_external\_semaphore and its various sub-extensions. If you don't specify them, then the `VkDevice`'s implementation knows that you're not going to need to be able to turn a VkSemaphore into an externally-accessible mutex and back. So the implementation may be able to use a more efficient `VkSemaphore` implementation.

If the extension is always on, the device *must* assume that you're going to use it. And thus, any possible efficiency is lost.

> wouldn't it be easier to just create one VkInstance and one VkDevice with everything enabled?

How? If you have two `VkDevice`s, unless they are both attached to the same `VkPhysicalDevice`, there's no guarantee that "everything" is the same thing for both devices.

---

Cross-process Vulkan interop is *not* something external code is expected to define. There are extensions that provide various aspects of such interop.

> **Comments:**
> **username_0**: To clarify: When I mentioned “cross-program”, I was referring to for example an executable calling into a third-party library from the same thread, rather than anything like cross-process interop. But it may fit the same ballpark regardless.  
> **username_1**: @username_0: In that case, the client third-party library and the calling layer should both agree on such things. That is, as part of the client library's documentation, it says "you must have enabled extensions/features X, Y, Z" or it has a way to inform you of what extensions/features are enabled.  

---

