<p>So, I'll start by saying I'm not a driver developer, but I have read many comments and docs in this regard.</p>
<p>First of all, we can see how Khronos's own <a href="https://www.khronos.org/assets/uploads/developers/library/overview/Vk_201602_Overview_Feb16.pdf#page=13" rel="nofollow noreferrer">slides</a> on presentation day were mentioning some rather vague &quot;any OpenGL ES 3.1 GPU&quot; (or desktop 4.X). This means <a href="https://www.anandtech.com/show/7867/khronos-announces-opengl-es-31" rel="nofollow noreferrer">something</a> added around that mark would be the secret to it. Compute shaders are definitively [at least one of] the things, being confirmed <a href="https://pcper.com/2015/03/gdc-15-what-is-vulkan-glnext-spir-v-and-opencl-2-1/" rel="nofollow noreferrer">here</a>, by an <a href="https://youtu.be/2ryvYS47V0E?t=3176" rel="nofollow noreferrer">Intel developer</a>, and in <a href="https://www.khronos.org/registry/vulkan/specs/1.1/pdf/vkspec.pdf" rel="nofollow noreferrer">the spec</a> with no possible unsupported value for <code>MaxComputeWorkGroupSize</code> and this likely smoking gun:</p>
<blockquote>
<p>If an implementation exposes any queue family that supports graphics
operations, at least one queue family of at least one physical device
exposed by the implementation <strong>must</strong> support both graphics and
compute operations.</p>
</blockquote>
<p>In addition to that though, it could <em>also</em> be there are other mandatory capabilities (such as indirect draws or <a href="https://gitlab.freedesktop.org/mesa/mesa/-/issues/6747#note_1702538" rel="nofollow noreferrer">load&amp;store</a>, mentioned in the comments above too). But I have some slight difficulty interpreting the document. With the exception of <a href="https://www.khronos.org/registry/vulkan/specs/1.0/html/chap30.html#features-requirements" rel="nofollow noreferrer">robustBufferAccess</a>, it seems like just about anything else big you could imagine is optional (from anisotropic filter, to geometry and tessellation shaders, to any special number format other than good old float32)</p>
<p>This being the most hypothetically simple case then, doesn't mean it's all fine and dandy. Not having <a href="https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1004192-r600-gallium3d-now-effectively-at-opengl-4-4-a-nudge-away-from-gl-4-5/page2#post1004523" rel="nofollow noreferrer">virtual memory</a> will make your life a hell for example, and lack of other <a href="https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/vulkan/845690-amd-s-vulkan-driver-will-only-work-with-the-amdgpu-kernel-driver/page3#post845730" rel="nofollow noreferrer">architectural features</a> may basically nullify whatever theoretical advantage in speed the API has.</p>
<p>These links should also answer your wonders about ATi cards. Likely same story for NVidia then (aside of perhaps some microbenchmarks, I'm not sure how much <em>really</em> workable <a href="https://techreport.com/news/32191/nvidia-finally-lets-fermi-gpu-owners-enjoy-directx-12/" rel="nofollow noreferrer">Fermi's</a> 2-years-delayed bare-bones DX12 support eventually is). As for Intel, I don't know what you are talking about, Gen8 is supported since <a href="https://01.org/linuxgraphics/blogs/jekstrand/2016/open-source-vulkan-drivers-intel-hardware" rel="nofollow noreferrer">Day1</a> and in fact even <a href="https://stackoverflow.com/questions/41497142/can-i-install-a-vulkan-driver-on-my-3rd-gen-intel-ivy-bridge-integrated-gpu-on-u">Gen7</a> <em>shakily</em> works now.</p>
<p>Going even further back, I guess if any the question becomes &quot;what's so special about compute shaders again&quot;.</p>
<p>And, well, the thing isn't probably the very specific <a href="https://www.anandtech.com/show/2716/5" rel="nofollow noreferrer">feature</a> itself (because it's <a href="https://en.wikipedia.org/wiki/BrookGPU" rel="nofollow noreferrer">not that</a> you couldn't already do some sort of general purpose calculation even before the unified shader model), but more like the whole general GPU architecture needed to support it. Check <a href="https://www.gamedev.net/forums/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/5215019/" rel="nofollow noreferrer">this</a> for some backstory.</p>
<p>Before DX11 raised <a href="https://stackoverflow.com/questions/3332782/can-directcompute-really-be-used-on-a-dx10-1-gpu">the bar</a> for example, just think that you <a href="https://www.anandtech.com/show/2977/nvidia-s-geforce-gtx-480-and-gtx-470-6-months-late-was-it-worth-the-wait-/3" rel="nofollow noreferrer">couldn't</a> even run more than a single &quot;task&quot; on a Tesla GPU, without having to call a context switch (with comparable limitations also likely existing for TeraScale 1 and Gen6). And may God save us from when pixel and vertex units were separated hardware.</p>
<p>fun fact: it turns out that if you are a low-end <a href="https://www.anandtech.com/show/8649/arm-announces-mali-800-series-gpus-t860-t830-t820" rel="nofollow noreferrer">kind-of-modern</a> mobile gpu (rather than an old desktop card from a time when certain concepts hadn't even been invented yet), engineers can cut you down so much that even if you just sport D3D 9_3 feature level that's still potentially <a href="https://developer.arm.com/solutions/graphics/resources/faqs#vulkan_which" rel="nofollow noreferrer">enough</a> to support Vulkan.</p>
<p>EDIT: for such somewhat twisted reasons, it can also <a href="https://github.com/Yours3lf/rpi-vk-driver/issues/1" rel="nofollow noreferrer">happen</a> that while you are just GLES 2.0 compliant (and compute shaders themselves aren't supported atm, even though the architecture would be capable) a restricted version of Vulkan could also be possible. It doesn't give you everything, but it can still lead to benefits over just &quot;old apis&quot;.</p>

CC BY-SA 4.0
2019-07-09T01:49:24.947Z
2023-05-16T21:22:03.167Z
2023-05-16T21:22:03.167Z
mirh
<p>More out of curiosity than for any practical purpose, I'm wondering what is lacking from older GPUs that causes them to be unable to support Vulkan.</p>

<p>I know that some argue that some hardware, such as nVidia's Fermi series of GPUs, could support Vulkan in hardware but the vendors simply won't implement it for business reasons, but even disregarding that, there is obviously some most recent hardware that really doesn't support Vulkan, and I'm curious what they lack. Like, say, the nVidia Tesla GPUs, AMD's TeraScale (VLIW) GPUs, or Intel's Gen8 hardware.</p>

<p>I'm mostly curious in knowing if the features in Vulkan that precludes support for these GPUs are somewhat "peripheral" in the API (like, say, required support for some particular texture format that the API <em>could</em> have just as well not required but did anyway to create a baseline that was considered reasonable), or if it's truly central to the Vulkan model.</p>

CC BY-SA 3.0
2017-05-04T06:07:00.787Z
Is your question about older hardware or recent hardware? The title says "older" but your actual question text seems like your asking more about more recent models. I suspect the answer will be different between the 2.
user1118321
CC BY-SA 3.0
2017-05-04T10:37:50.000Z
I believe that the some of the required features (including compute! and coarse occlusion queries) and some of the required limits may be out of reach.
ratchet freak
CC BY-SA 3.0
2017-05-04T12:06:45.967Z
@user1118321: I mostly mean the most recent GPUs that don't support Vulkan. By "older" I just meant "old enough to not support it".
Dolda2000
CC BY-SA 3.0
2017-05-04T14:45:22.047Z
@Dolda2000: I don't think the question is well-founded. You list three pieces of hardware, but you assume that they don't have Vulkan implementations for non-"business reasons". Do you have a basis for such an assumption?
Nicol Bolas
CC BY-SA 3.0
2017-05-04T17:37:15.060Z
@NicolBolas: Sorry, it seems I made myself misunderstood. I really just intended to speak of whatever most recent hardware that technically cannot support Vulkan. Those three specific architectures were just my best guess on what those might be, but I'm entirely open to having guessed wrong.
Dolda2000
CC BY-SA 3.0
2017-05-04T18:08:02.143Z
@Dolda2000: But you already know why GL 3.x/D3D10-class hardware can't support Vulkan: because they don't have very obvious hardware features that Vulkan requires. So the only hardware you seem to be talking about is GL 4.x/D3D11-class hardware that doesn't have Vulkan implementations.
Nicol Bolas
CC BY-SA 3.0
2017-05-05T01:52:15.437Z
@NicolBolas What are these "very obvious hardware features"? I think this is an excellent question. Also, I'm not sure I follow that GL 3.x can't support Vulkan since there exist GPUs that support Vulkan and can't support GL 3.2 devices because of lacking geometry shaders.
aces
CC BY-SA 3.0
2017-05-05T02:10:45.760Z
@aces: The "very obvious features" in question would be compute shaders and image load/store. Obvious due to the fact that it's right there in the Vulkan specification that these are not optional. The only GPUs that can provide these yet aren't GL 3.x capable would be *mobile* GPUs. But they don't support OpenGL of any version; they support OpenGL ***ES*** versions.
Nicol Bolas
CC BY-SA 3.0
2017-05-05T02:31:46.450Z
@NicolBolas You should write this as an answer :), as well as explain what hardware changes are needed to support these.
aces
CC BY-SA 3.0
2017-05-05T11:57:47.993Z
It also raises the question in what way eg. Tesla GPUs don't support compute shaders. Since they support CUDA, why can they not support Vulkan compute shaders? Ie., what actual hardware feature do they lack that prevents them from running compute shaders.
Dolda2000
CC BY-SA 3.0
2017-10-01T18:06:38.220Z
@Dolda2000 But don't they in turn (theoretically) lack all the other things *apart* from compute shaders, like all the features related to rasterization and whatever graphics stuff?
Christian Rau
CC BY-SA 3.0
2017-10-02T00:54:25.097Z
@ChristianRau: I don't know, that's why I'm asking. :) That being said, though, I'm not aware of any rasterization features that Vulkan requires which haven't been in OpenGL for a long time.
Dolda2000
CC BY-SA 4.0
2019-06-17T11:07:45.300Z
Sure, but do Teslas even support (reasonably modern) OpenGL to begin with? Afterall, they're *deliberately* non-graphics.
Christian Rau
CC BY-SA 4.0
2019-06-19T21:33:58.740Z
@ChristianRau: I was referring to the Tesla microarchitecture, not the workstation GPU brand (blame nVidia for the confusion). Tesla is also used from the GeForce 8XXX series up to the 3XX series.
Dolda2000
<vulkan>
What prevents older GPUs from supporting Vulkan?
Dolda2000
# What prevents older GPUs from supporting Vulkan?

(Asked by: username_0 on 2017-05-03)

More out of curiosity than for any practical purpose, I'm wondering what is lacking from older GPUs that causes them to be unable to support Vulkan.

I know that some argue that some hardware, such as nVidia's Fermi series of GPUs, could support Vulkan in hardware but the vendors simply won't implement it for business reasons, but even disregarding that, there is obviously some most recent hardware that really doesn't support Vulkan, and I'm curious what they lack. Like, say, the nVidia Tesla GPUs, AMD's TeraScale (VLIW) GPUs, or Intel's Gen8 hardware.

I'm mostly curious in knowing if the features in Vulkan that precludes support for these GPUs are somewhat "peripheral" in the API (like, say, required support for some particular texture format that the API *could* have just as well not required but did anyway to create a baseline that was considered reasonable), or if it's truly central to the Vulkan model.

**Tags:** vulkan

> **Comments:**
> **username_1**: Is your question about older hardware or recent hardware? The title says "older" but your actual question text seems like your asking more about more recent models. I suspect the answer will be different between the 2.  
> **username_2**: I believe that the some of the required features (including compute! and coarse occlusion queries) and some of the required limits may be out of reach.  
> **username_0**: @username_1: I mostly mean the most recent GPUs that don't support Vulkan. By "older" I just meant "old enough to not support it".  
> **username_3**: @username_0: I don't think the question is well-founded. You list three pieces of hardware, but you assume that they don't have Vulkan implementations for non-"business reasons". Do you have a basis for such an assumption?  
> **username_0**: @username_3: Sorry, it seems I made myself misunderstood. I really just intended to speak of whatever most recent hardware that technically cannot support Vulkan. Those three specific architectures were just my best guess on what those might be, but I'm entirely open to having guessed wrong.  
> **username_3**: @username_0: But you already know why GL 3.x/D3D10-class hardware can't support Vulkan: because they don't have very obvious hardware features that Vulkan requires. So the only hardware you seem to be talking about is GL 4.x/D3D11-class hardware that doesn't have Vulkan implementations.  
> **username_4**: @username_3 What are these "very obvious hardware features"? I think this is an excellent question. Also, I'm not sure I follow that GL 3.x can't support Vulkan since there exist GPUs that support Vulkan and can't support GL 3.2 devices because of lacking geometry shaders.  
> **username_3**: @username_4: The "very obvious features" in question would be compute shaders and image load/store. Obvious due to the fact that it's right there in the Vulkan specification that these are not optional. The only GPUs that can provide these yet aren't GL 3.x capable would be *mobile* GPUs. But they don't support OpenGL of any version; they support OpenGL ***ES*** versions.  
> **username_4**: @username_3 You should write this as an answer :), as well as explain what hardware changes are needed to support these.  
> **username_0**: It also raises the question in what way eg. Tesla GPUs don't support compute shaders. Since they support CUDA, why can they not support Vulkan compute shaders? Ie., what actual hardware feature do they lack that prevents them from running compute shaders.  
> **username_5**: @username_0 But don't they in turn (theoretically) lack all the other things *apart* from compute shaders, like all the features related to rasterization and whatever graphics stuff?  
> **username_0**: @username_5: I don't know, that's why I'm asking. :) That being said, though, I'm not aware of any rasterization features that Vulkan requires which haven't been in OpenGL for a long time.  
> **username_5**: Sure, but do Teslas even support (reasonably modern) OpenGL to begin with? Afterall, they're *deliberately* non-graphics.  
> **username_0**: @username_5: I was referring to the Tesla microarchitecture, not the workstation GPU brand (blame nVidia for the confusion). Tesla is also used from the GeForce 8XXX series up to the 3XX series.  

---

## 1 answers

### Answer by username_6 on 2019-07-09. Score: 7 | Accepted answer

So, I'll start by saying I'm not a driver developer, but I have read many comments and docs in this regard.

First of all, we can see how Khronos's own [slides](https://www.khronos.org/assets/uploads/developers/library/overview/Vk_201602_Overview_Feb16.pdf#page=13) on presentation day were mentioning some rather vague "any OpenGL ES 3.1 GPU" (or desktop 4.X). This means [something](https://www.anandtech.com/show/7867/khronos-announces-opengl-es-31) added around that mark would be the secret to it. Compute shaders are definitively [at least one of] the things, being confirmed [here](https://pcper.com/2015/03/gdc-15-what-is-vulkan-glnext-spir-v-and-opencl-2-1/), by an [Intel developer](https://youtu.be/2ryvYS47V0E?t=3176), and in [the spec](https://www.khronos.org/registry/vulkan/specs/1.1/pdf/vkspec.pdf) with no possible unsupported value for `MaxComputeWorkGroupSize` and this likely smoking gun:

> If an implementation exposes any queue family that supports graphics
> operations, at least one queue family of at least one physical device
> exposed by the implementation **must** support both graphics and
> compute operations.

In addition to that though, it could *also* be there are other mandatory capabilities (such as indirect draws or [load&store](https://gitlab.freedesktop.org/mesa/mesa/-/issues/6747#note_1702538), mentioned in the comments above too). But I have some slight difficulty interpreting the document. With the exception of [robustBufferAccess](https://www.khronos.org/registry/vulkan/specs/1.0/html/chap30.html#features-requirements), it seems like just about anything else big you could imagine is optional (from anisotropic filter, to geometry and tessellation shaders, to any special number format other than good old float32)

This being the most hypothetically simple case then, doesn't mean it's all fine and dandy. Not having [virtual memory](https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1004192-r600-gallium3d-now-effectively-at-opengl-4-4-a-nudge-away-from-gl-4-5/page2#post1004523) will make your life a hell for example, and lack of other [architectural features](https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/vulkan/845690-amd-s-vulkan-driver-will-only-work-with-the-amdgpu-kernel-driver/page3#post845730) may basically nullify whatever theoretical advantage in speed the API has.

These links should also answer your wonders about ATi cards. Likely same story for NVidia then (aside of perhaps some microbenchmarks, I'm not sure how much *really* workable [Fermi's](https://techreport.com/news/32191/nvidia-finally-lets-fermi-gpu-owners-enjoy-directx-12/) 2-years-delayed bare-bones DX12 support eventually is). As for Intel, I don't know what you are talking about, Gen8 is supported since [Day1](https://01.org/linuxgraphics/blogs/jekstrand/2016/open-source-vulkan-drivers-intel-hardware) and in fact even [Gen7](https://stackoverflow.com/questions/41497142/can-i-install-a-vulkan-driver-on-my-3rd-gen-intel-ivy-bridge-integrated-gpu-on-u) *shakily* works now.

Going even further back, I guess if any the question becomes "what's so special about compute shaders again".

And, well, the thing isn't probably the very specific [feature](https://www.anandtech.com/show/2716/5) itself (because it's [not that](https://en.wikipedia.org/wiki/BrookGPU) you couldn't already do some sort of general purpose calculation even before the unified shader model), but more like the whole general GPU architecture needed to support it. Check [this](https://www.gamedev.net/forums/topic/666419-what-are-your-opinions-on-dx12vulkanmantle/5215019/) for some backstory.

Before DX11 raised [the bar](https://stackoverflow.com/questions/3332782/can-directcompute-really-be-used-on-a-dx10-1-gpu) for example, just think that you [couldn't](https://www.anandtech.com/show/2977/nvidia-s-geforce-gtx-480-and-gtx-470-6-months-late-was-it-worth-the-wait-/3) even run more than a single "task" on a Tesla GPU, without having to call a context switch (with comparable limitations also likely existing for TeraScale 1 and Gen6). And may God save us from when pixel and vertex units were separated hardware.

fun fact: it turns out that if you are a low-end [kind-of-modern](https://www.anandtech.com/show/8649/arm-announces-mali-800-series-gpus-t860-t830-t820) mobile gpu (rather than an old desktop card from a time when certain concepts hadn't even been invented yet), engineers can cut you down so much that even if you just sport D3D 9\_3 feature level that's still potentially [enough](https://developer.arm.com/solutions/graphics/resources/faqs#vulkan_which) to support Vulkan.

EDIT: for such somewhat twisted reasons, it can also [happen](https://github.com/Yours3lf/rpi-vk-driver/issues/1) that while you are just GLES 2.0 compliant (and compute shaders themselves aren't supported atm, even though the architecture would be capable) a restricted version of Vulkan could also be possible. It doesn't give you everything, but it can still lead to benefits over just "old apis".


---

