6 ms·

Vulkan was never intended to be for "graphics programming newbies". It's intended to be the thing you would build a more developer-friendly API on top of.

by skohan 5y ago

Jweb_Guru 5y ago
Look at the state of Vulkan drivers in practice, the "fastest" ones in benchmarks of actual AAA games do tons of work that was supposed to be done in userspace (like, that was the whole point!). I agree in principle that it's important to have an API expose all the ugly low level details, but doing so and then telling people not to actually use it is pretty much obviously going to result in a suboptimal compromise like what we have today. Of course people are going to try to code against vanilla Vulkan; I think things would be different if it had shipped side by side with something like a robust implementation of WebGPU, so people who weren't able to use big name game engines had something to fall back on, but that's not what happened.
- fctorial 5y ago
  > the "fastest" ones in benchmarks of actual AAA games do tons of work that was supposed to be done in userspace Can you give some examples preferably with links to source.
- flohofwoe 5y ago
  I think the counter-intuitive "hindsight-is-20/20" fact is that a higher level, more abstract API provides more wiggle room for GPU vendors to implement optimizations for their specific GPU architecture. "Abstract API" doesn't mean it has to be mess like what OpenGL became after 1.x, but one problem is that many people think that Vulkan was the only possible alternative future to OpenGL, while ignoring APIs like D3D11 and Metal which would have been a better starting point for an OpenGL successor.
  - pjmlp 5y ago
    If you look at Khronos slideware that is kind of the official message, naturally that is what those people end up thinking, specially if they are newbies looking into learning portable 3D APIs.
  - skohan 5y ago
    Idk as an "intermediate" graphics programmer, the explicitness and lack of abstraction in Vulkan is one of the killer features for me. "Wiggle room" in higher-level API's like OpenGL is one of the things that made them impossible to deliver consistent results with. With Vulkan there's more typing, but once you get something working it's going to work the same pretty much everywhere. I kind of see it as a non-issue. It seems like Vulkan's target audience was specifically elite developers who wanted the most control possible, and based on the results which have been achieved in products like Doom 2016/Eternal it seems like it's working for them. I suspect WebGPU will be the OpenGL successor for everyone working with graphics who isn't at an AAA game studio.
    - HelloNurse 5y ago
      "Wiggle room" means, for example, that OpenGL drivers might look at the name of your executable to apply different hacks and profiles. It means that you write perfect code, and then who knows what will happen. Thanks, but no thanks.
      - flohofwoe 5y ago
        Not what meant, besides, if you read NVIDIA and AMD driver release notes carefully, you will find that these also contain game-specific fixes in the Vulkan drivers. It's just rarer because there are not many games using Vulkan.
    - flohofwoe 5y ago
      As I wrote above, OpenGL is an exeptionally bad counter example to Vulkan because it's just a massive soup of knobs and dials. D3D11 and Metal had this specific problem fixed already, and should have been used as base for an OpenGL successor instead of going all radical with Mantle. Vulkan is basically a GPU-programming API with some support for triangle rendering, great for compute workloads, not so great for rendering triangles. At the very least, Khronos should provide additional layers on top of Vulkan to simplify traditional rendering tasks, basically providing one or more optional API layers that are closer to Metal and D3D11.
- shmerl 5y ago
  radv is one of the fastest ones. What does it do that it shouldn't?
  - Jweb_Guru 5y ago
    radv is one of the ones I'm referring to, it's open source so we can see the tricks they use. One example: it spawns a thread behind your back in order to execute command buffers in order to make the queue submit appear nonblocking (or at least fast). This is completely contrary to the spirit of the Vulkan spec which deliberately doesn't provide any convenience mechanisms for things like callbacks on command buffer completion, precisely because these would require runtime threads to be around. The user has no control over this thread, including where it spawns or its priority (how could it, when it's an implementation detail of the driver?) nor can they take advantage of this knowledge to improve synchronization on the CPU side (e.g. by removing external synchronization around queues). Contrast this with the situation on Metal (explicit runtime that spawns threads, and explicit callbacks to be able to take advantage of that) or DirectX 12 (explicit runtime that works for the average case, with extremely fine grained control provided over the threading model, priorities, etc., including being able to turn them off completely if you really need it). Both of these are clearly much better models because they are actually exposing the detail that seems obvious in hindsight (applications need queue submission to be nonblocking) and are able to provide much more flexible, efficient, and useful APIs as a result. By leaving everything up to the user, Vulkan in practice ends up underperforming its competitors unless the drivers patch up the work--at which point you have the unfortunate situation where you have people targeting a low-level API running on a high-level runtime. It's this, not some dumb digression about extensions, that IMO make Vulkan kind of disappointing--it's definitely not a failure, but it could've been much better than it was.
    - shmerl 5y ago
      As long as it doesn't violate the spec, I'd look at actual performance results of it. I.e. if it interferes with usage or creates some kind of performance degradation for the applications, then it's indeed a problem. Otherwise this requirement should have been an explicit part of the spec. I.e. I'd imagine if this is a real problem, there should be some RFC for the updated version of the API where this is prohibited or some requirements are added about how to control it.
pjmlp 5y ago
When Khronos states that OpenGL is done, newbies are going to try to learn an API that is actually getting updates, regardless of its intended target.
- skohan 5y ago
  And if I market a laser cutter, and you decide to use it to cut your steak at dinner, am I to blame if you find it too complicated to operate?
  - pjmlp 5y ago
    If you let knives to rust, I don't have other option left when they run out.
fctorial 5y ago
You don't need to be a graphics programming veteran to learn vulkan either. The official spec is quite approachable even for newbies.
- skohan 5y ago
  Yeah it is a very well written spec. I've been working on an LSP implementation recently, and I wish the spec was even 10% as clear as Vulkan's. Also the official tutorial is really excellent. What I think is unapproachable about Vulkan is just the complexity of the problem space. There are a lot of concepts to be aware of just to get the first triangle on the screen (swap-chain, synchronization, render-passes etc.), so in my experience it took quite a few hours of working with it to build an intuition about how everything fits together. And that was coming from an OpenGL background where 70% of the concepts were familiar. I can imagine if you were coming from something like web front-end development, Vulkan could seem pretty inscrutable. But I will say, since I did cross that bridge, Vulkan became much more intuitive to me than OpenGL. The fact that everything's explicit means there's no mysteries, and the declarative style becomes quite guessable after some time.
- dangerbird2 5y ago
  As verbose as it often is, the lack of an opengl-style state machine in Vulkan (or Wgpu/Metal/Dx12 for that matter) makes it so much easier to reason with. About 70% of the bugs I've had to deal with in OpenGL involved me forgetting to unbind some buffer object or shader program from OGL's global state. From my experience the "simplicity" of OpenGL is often negated by having to write wrappers around every OpenGL resource type for safe resource management via RAII. Not to mention, error handling is a huge improvement in Vulkan. In openGL, errors are stored in stack that gets popped by calling glGetError. A rookie mistake is only calling the function once, when you really have to call glGetError until the stack is empty every time you check for errors to catch all errors. By contrast, Vulkan just returns a vkResult structure on every function that can fail.

Vulkan was never intended to be for "graphics programming newbies". It's intended to be the thing you would build a more developer-friendly API on top of.

by skohan 5y ago

Vulkan was never intended to be for "graphics programming newbies". It's intended to be the thing you would build a more developer-friendly API on top of.

Jweb_Guru 5y ago

Look at the state of Vulkan drivers in practice, the "fastest" ones in benchmarks of actual AAA games do tons of work that was supposed to be done in userspace (like, that was the whole point!). I agree in principle that it's important to have an API expose all the ugly low level details, but doing so and then telling people not to actually use it is pretty much obviously going to result in a suboptimal compromise like what we have today. Of course people are going to try to code against vanilla Vulkan; I think things would be different if it had shipped side by side with something like a robust implementation of WebGPU, so people who weren't able to use big name game engines had something to fall back on, but that's not what happened.

fctorial 5y ago
> the "fastest" ones in benchmarks of actual AAA games do tons of work that was supposed to be done in userspace Can you give some examples preferably with links to source.
flohofwoe 5y ago
I think the counter-intuitive "hindsight-is-20/20" fact is that a higher level, more abstract API provides more wiggle room for GPU vendors to implement optimizations for their specific GPU architecture. "Abstract API" doesn't mean it has to be mess like what OpenGL became after 1.x, but one problem is that many people think that Vulkan was the only possible alternative future to OpenGL, while ignoring APIs like D3D11 and Metal which would have been a better starting point for an OpenGL successor.
- pjmlp 5y ago
  If you look at Khronos slideware that is kind of the official message, naturally that is what those people end up thinking, specially if they are newbies looking into learning portable 3D APIs.
- skohan 5y ago
  Idk as an "intermediate" graphics programmer, the explicitness and lack of abstraction in Vulkan is one of the killer features for me. "Wiggle room" in higher-level API's like OpenGL is one of the things that made them impossible to deliver consistent results with. With Vulkan there's more typing, but once you get something working it's going to work the same pretty much everywhere. I kind of see it as a non-issue. It seems like Vulkan's target audience was specifically elite developers who wanted the most control possible, and based on the results which have been achieved in products like Doom 2016/Eternal it seems like it's working for them. I suspect WebGPU will be the OpenGL successor for everyone working with graphics who isn't at an AAA game studio.
  - HelloNurse 5y ago
    "Wiggle room" means, for example, that OpenGL drivers might look at the name of your executable to apply different hacks and profiles. It means that you write perfect code, and then who knows what will happen. Thanks, but no thanks.
    - flohofwoe 5y ago
      Not what meant, besides, if you read NVIDIA and AMD driver release notes carefully, you will find that these also contain game-specific fixes in the Vulkan drivers. It's just rarer because there are not many games using Vulkan.
  - flohofwoe 5y ago
    As I wrote above, OpenGL is an exeptionally bad counter example to Vulkan because it's just a massive soup of knobs and dials. D3D11 and Metal had this specific problem fixed already, and should have been used as base for an OpenGL successor instead of going all radical with Mantle. Vulkan is basically a GPU-programming API with some support for triangle rendering, great for compute workloads, not so great for rendering triangles. At the very least, Khronos should provide additional layers on top of Vulkan to simplify traditional rendering tasks, basically providing one or more optional API layers that are closer to Metal and D3D11.
shmerl 5y ago
radv is one of the fastest ones. What does it do that it shouldn't?
- Jweb_Guru 5y ago
  radv is one of the ones I'm referring to, it's open source so we can see the tricks they use. One example: it spawns a thread behind your back in order to execute command buffers in order to make the queue submit appear nonblocking (or at least fast). This is completely contrary to the spirit of the Vulkan spec which deliberately doesn't provide any convenience mechanisms for things like callbacks on command buffer completion, precisely because these would require runtime threads to be around. The user has no control over this thread, including where it spawns or its priority (how could it, when it's an implementation detail of the driver?) nor can they take advantage of this knowledge to improve synchronization on the CPU side (e.g. by removing external synchronization around queues). Contrast this with the situation on Metal (explicit runtime that spawns threads, and explicit callbacks to be able to take advantage of that) or DirectX 12 (explicit runtime that works for the average case, with extremely fine grained control provided over the threading model, priorities, etc., including being able to turn them off completely if you really need it). Both of these are clearly much better models because they are actually exposing the detail that seems obvious in hindsight (applications need queue submission to be nonblocking) and are able to provide much more flexible, efficient, and useful APIs as a result. By leaving everything up to the user, Vulkan in practice ends up underperforming its competitors unless the drivers patch up the work--at which point you have the unfortunate situation where you have people targeting a low-level API running on a high-level runtime. It's this, not some dumb digression about extensions, that IMO make Vulkan kind of disappointing--it's definitely not a failure, but it could've been much better than it was.
  - shmerl 5y ago
    As long as it doesn't violate the spec, I'd look at actual performance results of it. I.e. if it interferes with usage or creates some kind of performance degradation for the applications, then it's indeed a problem. Otherwise this requirement should have been an explicit part of the spec. I.e. I'd imagine if this is a real problem, there should be some RFC for the updated version of the API where this is prohibited or some requirements are added about how to control it.

pjmlp 5y ago

When Khronos states that OpenGL is done, newbies are going to try to learn an API that is actually getting updates, regardless of its intended target.

skohan 5y ago
And if I market a laser cutter, and you decide to use it to cut your steak at dinner, am I to blame if you find it too complicated to operate?
- pjmlp 5y ago
  If you let knives to rust, I don't have other option left when they run out.

fctorial 5y ago

You don't need to be a graphics programming veteran to learn vulkan either. The official spec is quite approachable even for newbies.

skohan 5y ago
Yeah it is a very well written spec. I've been working on an LSP implementation recently, and I wish the spec was even 10% as clear as Vulkan's. Also the official tutorial is really excellent. What I think is unapproachable about Vulkan is just the complexity of the problem space. There are a lot of concepts to be aware of just to get the first triangle on the screen (swap-chain, synchronization, render-passes etc.), so in my experience it took quite a few hours of working with it to build an intuition about how everything fits together. And that was coming from an OpenGL background where 70% of the concepts were familiar. I can imagine if you were coming from something like web front-end development, Vulkan could seem pretty inscrutable. But I will say, since I did cross that bridge, Vulkan became much more intuitive to me than OpenGL. The fact that everything's explicit means there's no mysteries, and the declarative style becomes quite guessable after some time.
dangerbird2 5y ago
As verbose as it often is, the lack of an opengl-style state machine in Vulkan (or Wgpu/Metal/Dx12 for that matter) makes it so much easier to reason with. About 70% of the bugs I've had to deal with in OpenGL involved me forgetting to unbind some buffer object or shader program from OGL's global state. From my experience the "simplicity" of OpenGL is often negated by having to write wrappers around every OpenGL resource type for safe resource management via RAII. Not to mention, error handling is a huge improvement in Vulkan. In openGL, errors are stored in stack that gets popped by calling glGetError. A rookie mistake is only calling the function once, when you really have to call glGetError until the stack is empty every time you check for errors to catch all errors. By contrast, Vulkan just returns a vkResult structure on every function that can fail.