11
$\begingroup$

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.

Improve this question
$\endgroup$
14
  • 1
    $\begingroup$ 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. $\endgroup$
    – user1118321
    May 4, 2017 at 6:07
  • 1
    $\begingroup$ @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? $\endgroup$
    – Nicol Bolas
    May 4, 2017 at 14:45
  • 2
    $\begingroup$ @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. $\endgroup$
    – Nicol Bolas
    May 5, 2017 at 2:10
  • 4
    $\begingroup$ @NicolBolas You should write this as an answer :), as well as explain what hardware changes are needed to support these. $\endgroup$
    – aces
    May 5, 2017 at 2:31
  • 2
    $\begingroup$ 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. $\endgroup$
    – Dolda2000
    May 5, 2017 at 11:57

1 Answer 1

Reset to default
7
$\begingroup$

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 on presentation day were mentioning some rather vague "any OpenGL ES 3.1 GPU" (or desktop 4.X). This means something added around that mark would be the secret to it. Compute shaders are definitively [at least one of] the things, being confirmed here, by an Intel developer, and in the spec 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, mentioned in the comments above too). But I have some slight difficulty interpreting the document. With the exception of robustBufferAccess, 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 will make your life a hell for example, and lack of other architectural features 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 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 and in fact even Gen7 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 itself (because it's not that 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 for some backstory.

Before DX11 raised the bar for example, just think that you couldn't 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 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 to support Vulkan.

EDIT: for such somewhat twisted reasons, it can also happen 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".

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.