8 ms·

Beginners Guide to Vulkan

248 points by deafcalculus 9y ago

mncharity 9y ago
For folks curious about WebGL in a Vulkan world, there's https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas... .
- kllrnohj 9y ago
  Not to be overly harsh about their work but that just screams "me too!" instead of solving an actual problem. Vulkan is a low-level, highly verbose API designed to extract maximum performance and leverage multiple threads to deal with slower aspects of rendering. Then you chuck that into a single-threaded, slow (relatively) runtime where method calls to the actual implementation are particularly expensive (JavaScript -> native transitions ain't cheap), and that's supposed to be a good idea? Why? Who is supposed to use this for anything useful? Instead of just porting native features to the web for the sake of porting them make it easier to make use of the hardware's capabilities. Let me throw a GPU shader into a CSS3 transition animation or something like that, for example. That'd be cool and potentially useful instead of a system where you can port some game to the web for the sake of porting it to the web where nobody will ever use it because it sucks compared to the vastly superior native version of the game.
  - pshc 9y ago
    I imagine the next step is to provide a WebAssembly binding. edit: "The API has to execute efficiently on WebAssembly and in multi-threaded environment. That means no GC allocations during the rendering loop in order to avoid the garbage collection pauses."
    - kllrnohj 9y ago
      Well WebAssembly is another thing I'd question the usefulness of. It's going to result in threading finally coming to JS which is nice, but the rest of it is more like a showing of of technical infrastructure for the sake of it instead of helping apps with problems they have.
      - pshc 9y ago
        I would argue that having to write apps in JS, or transpiling to the JS runtime, is a problem for many people.
        kllrnohj 9y ago
        Sure but you could imagine something more like a .NET or JVM bytecode instead, which would be a more practical target for transpiled web apps instead of webasm. Instead we ended up with a stack machine & sbrk.
        pshc 9y ago
        But in what sense would an extra VM layer be more practical? Maybe this is where we disagree. I'm not fond of VMs, especially those two. C++ or Rust -> wasm bytecode is great. Soon we'll be writing directly to command buffers, no fuss.
        kllrnohj 9y ago
        If you want to do C++/Rust direct to command buffers why on earth would you bother with the pile of overhead that is a modern web browser? But ~nobody wants to build UIs like that anyway, so what's your target audience?
        pshc 9y ago
        Games and other 3D applications? Getting people in-game (say a lazily loaded demo with slightly less perf) with one click is huge.
        kllrnohj 9y ago
        No, it isn't. Games are already served by consoles first (which obviously won't run webasm), and steam second. There's no market there, and it's already one-click to launch steam to the game in question. Where it will then download in a medium suitable to handling the downloading & updating of a game's assets instead (which, even for a demo, is in the gigabyte range - you aren't lazy loading this). As for 3D applications what 3D applications? Do you really think Maya is going to be ported to a browser? Why would they bother? Why would they restrict themselves like that? The web has no advantages in this space, and the needs of those markets is already being served with superior technology and infrastructure.
  - pcwalton 9y ago
    > Then you chuck that into a single-threaded, slow (relatively) runtime Slow relative to C++, sure. But JS is very fast relative to pretty much any other widely used dynamic language. If we should expose Vulkan bindings to dynamic languages (and why not?) JS is the obvious first choice for a target, given its speed and popularity. > JavaScript -> native transitions ain't cheap They're actually very cheap nowadays, because so many benchmarks stress the DOM and C++-implemented builtins. Driver calls, even with Vulkan, far exceed the cost of JS-to-native transitions. glDrawElements() is probably at least 100x slower than a JS-to-native call, the latter of which has latencies measured in nanoseconds. > Let me throw a GPU shader into a CSS3 transition animation or something like that, for example. Please, let's not. This will neither be good for designers (modern GPU programming has an enormous learning curve compared to CSS) nor browser developers (shaders would break batching and would expose too many engine-specific internal details).
    - pandaman 9y ago
      I don't think glDrawElements() goes into the driver though (at least there is no sane reason for it I can imagine, you only need to go into the driver to kick a command buffer at the end of frame). Nevertheless, even if some implementations actually do call driver, the GP's point is that the whole point of Vulkan is getting rid of global state to allow parallel command buffer creation. JS is single threaded so, no matter how cheap or expensive the calls are, you won't be able to take advantage of Vulkan since you are running just one thread.
      - nhaehnle 9y ago
        Of course glDrawElements() has to go into the driver, because it needs to do hardware-specific work. This is obviously true in OpenGL(ES), but even if you were to implement it via a translation layer to Vulkan, you still have to call the various Vulkan-equivalent commands, at the very least vkCmdDrawIndexed. Here's an implementation to make it painfully obvious why that has to involve the driver: https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6246833a2a2d5f034/src/amd/vulkan/radv_cmd_buffer.c#L2758 https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6...
Impossible 9y ago
Oculus Tiny Room is linked, but Valve also has a pretty good minimal Vulkan + OpenVR example in the OpenVR SDK called hellovr_vulkan (https://github.com/ValveSoftware/openvr/blob/master/samples/hellovr_vulkan/hellovr_vulkan_main.cpp https://github.com/ValveSoftware/openvr/blob/master/samples/...). On HN this might be attractive because people tend to complain about Windows only software, and all of Valve's samples use SDL and in theory run on Mac OS X and Linux. The OpenVR example is a little bit more verbose, but it does have some extra functionality, like drawing render models (controllers) provided by the API.
- uep 9y ago
  Thanks for this! I happen to have a Vive and have been wanting to get my game engine outputting to it. I am primarily focused on Linux.
  - rocky1138 9y ago
    Can we see your engine?
Nimsical 9y ago
I clicked cause I thought it was about Star Trek. Always forget there's a library with that name.
- sleavey 9y ago
  Disappointed it's not on Khan Academy.
  - majewsky 9y ago
    KKKKHHHHHAAAAAAANNN!
- khedoros1 9y ago
  > Always forget there's a library with that name. And that "Vulcan" is properly spelled with a "c" in Star Trek? (At least in English...I suppose it might be different in other languages).
- fsiefken 9y ago
  Yes, me too, I really love conlangs. For the Vulcan language see: http://www.vli-online.org/vlif.htm http://www.vli-online.org/vlif.htm https://scifi.stackexchange.com/questions/1453/how-realized-is-the-vulcan-language https://scifi.stackexchange.com/questions/1453/how-realized-...
alistproducer2 9y ago
Can someone give me a non-graphical use-case for learning Vulkan or just GPU-based programming in general? I've heard of hardware acceleration. Is it something like writing your routines in a language like Vulkan and offloading the computation to the GPU?
- jeremiep 9y ago
  Massive SIMD works great on the GPU. Compute shaders are already a non-graphical use-case on the GPU. You get high bandwidth but also high latency, so its best for a few large batches rather than lots of small batches. There is also overhead to uploading and downloading data to and from the GPU. So you want to save more time than you spend there.
- kllrnohj 9y ago
  The use cases for GPU compute are fairly narrow. You need something that is embarrassingly parallel and deals with almost nothing but floats. You also need something isolated enough that you're ok with paying the PCI-E bandwidth overhead to send it to the GPU & receive the results back from the GPU.
  - deleted 9y ago
    [deleted]
  - pcwalton 9y ago
    > You need something that…deals with almost nothing but floats. This hasn't been true for years. GPU integer compute is quite good these days.
    - kllrnohj 9y ago
      GPUs will handle ints just fine, but it's not what they are best at. They are best at fp32, and depending on the GPU the gap is rather substantial. The performance characteristics of integer ops is also kinda weird.
      - 9y ago
deleted 9y ago
[deleted]
Kiro 9y ago
> It reminds me of a lot of the attitudes surrounding C++ when I was first learning it-- yes, it's more lines of code, but that doesn't mean it can't be a fine place for a beginner to start learning. Sure, but Vulkan really feels like another level of complexity. OpenGL is simple in comparison.
- ATsch 9y ago
  Well, libraries and frameworks have solved problems like that before and probably will again.
  - robotresearcher 9y ago
    Low level graphics programming is tough, specialist work. Imagine a relatively simple stateful API layer over the top of this stuff, widely adopted and with an open spec. We could call it the Open Graphics Library, or OpenGL for short.
    - kuschku 9y ago
      And a horribly painful codebase that is a horror to work with. Nowadays people are more comfortable with having objects that represent something, and executing operations on them, than having to bind an object to a global variable, execute a global procedure, and unbinding it.
      - robotresearcher 9y ago
        You think so? I think people like to call functions with comprehensible arguments. I don't agree that people like to bind an object to a global variable, execute a global procedure, and unbind it. Does that sound like the API of anyone's dreams? The binding and unbinding sounds like pure overhead to me. I understand that very high performance and easy API may not be achievable, but seriously, the modern graphics APIs are hard to love.
        kuschku 9y ago
atemerev 9y ago
800 lines of code to render a triangle. OK. I understand the need of being explicit, but why not include some reasonable defaults? When you need that last drop of performance, you could opt out of those defaults, but specifying everything by hand... OK, OK, I understand. Perhaps Vulkan is a compiler target. It was never intended for someone to write Vulkan code by hand. Just code in some higher-level API or language and get everything compiled into low-level Vulkan calls. I surely hope so, for the sake of my sanity. Right? Right?
- corysama 9y ago
  It's not intended for someone to use Vulkan to render a triangle. If you want to render a triangle (or merely a million triangles), just throw together some simple OpenGL code and you'll have no problems assuming basic optimizations (large batches). If you really need Vulkan's advantages, you are committing yourself to a whole lot more than 800 lines of code, Vulkan or no. The setup code will be done once, then you'll move on to many thousands of lines of pipeline code that will take the vast majority of dev time. The GL vs Vulkan question is more about what you get in the end. GL takes care of a lot for you, but that makes writing a highly specialized pipeline more complicated. Vulkan makes everything complicated because specialization is presumed to be the goal.
  - atemerev 9y ago
    Firstly, I am worried that OpenGL development seems to be stalled and it looks like its going into maintenance mode, where Vulkan is where all action happens. It is increasingly pushed as a replacement to OpenGL, implicitly or explicitly, and if it will be the only mainstream alternative, I am somewhat worried. Secondly, I am worried that there are no mid-level 3D graphic toolkits. We have low-level (very very low-level) like Vulkan, or high-level stuff like Three.js and game engines (which are not what I need, as I write realtime scientific visualization code). What I want is something like imgui (https://github.com/ocornut/imgui https://github.com/ocornut/imgui), but for 3D. Simple, powerful, and bloat-free. However, I can't find anything like this.
    - 9y ago

248 points by deafcalculus 9y ago

For folks curious about WebGL in a Vulkan world, there's https://github.com/KhronosGroup/WebGLNext-Proposals/tree/master/Obsidian-Mozilla https://github.com/KhronosGroup/WebGLNext-Proposals/tree/mas... .

kllrnohj 9y ago
Not to be overly harsh about their work but that just screams "me too!" instead of solving an actual problem. Vulkan is a low-level, highly verbose API designed to extract maximum performance and leverage multiple threads to deal with slower aspects of rendering. Then you chuck that into a single-threaded, slow (relatively) runtime where method calls to the actual implementation are particularly expensive (JavaScript -> native transitions ain't cheap), and that's supposed to be a good idea? Why? Who is supposed to use this for anything useful? Instead of just porting native features to the web for the sake of porting them make it easier to make use of the hardware's capabilities. Let me throw a GPU shader into a CSS3 transition animation or something like that, for example. That'd be cool and potentially useful instead of a system where you can port some game to the web for the sake of porting it to the web where nobody will ever use it because it sucks compared to the vastly superior native version of the game.
- pshc 9y ago
  I imagine the next step is to provide a WebAssembly binding. edit: "The API has to execute efficiently on WebAssembly and in multi-threaded environment. That means no GC allocations during the rendering loop in order to avoid the garbage collection pauses."
  - kllrnohj 9y ago
    Well WebAssembly is another thing I'd question the usefulness of. It's going to result in threading finally coming to JS which is nice, but the rest of it is more like a showing of of technical infrastructure for the sake of it instead of helping apps with problems they have.
    - pshc 9y ago
      I would argue that having to write apps in JS, or transpiling to the JS runtime, is a problem for many people.
      - kllrnohj 9y ago
        Sure but you could imagine something more like a .NET or JVM bytecode instead, which would be a more practical target for transpiled web apps instead of webasm. Instead we ended up with a stack machine & sbrk.
        pshc 9y ago
        But in what sense would an extra VM layer be more practical? Maybe this is where we disagree. I'm not fond of VMs, especially those two. C++ or Rust -> wasm bytecode is great. Soon we'll be writing directly to command buffers, no fuss.
        kllrnohj 9y ago
        If you want to do C++/Rust direct to command buffers why on earth would you bother with the pile of overhead that is a modern web browser? But ~nobody wants to build UIs like that anyway, so what's your target audience?
        pshc 9y ago
        Games and other 3D applications? Getting people in-game (say a lazily loaded demo with slightly less perf) with one click is huge.
        kllrnohj 9y ago
        No, it isn't. Games are already served by consoles first (which obviously won't run webasm), and steam second. There's no market there, and it's already one-click to launch steam to the game in question. Where it will then download in a medium suitable to handling the downloading & updating of a game's assets instead (which, even for a demo, is in the gigabyte range - you aren't lazy loading this). As for 3D applications what 3D applications? Do you really think Maya is going to be ported to a browser? Why would they bother? Why would they restrict themselves like that? The web has no advantages in this space, and the needs of those markets is already being served with superior technology and infrastructure.
- pcwalton 9y ago
  > Then you chuck that into a single-threaded, slow (relatively) runtime Slow relative to C++, sure. But JS is very fast relative to pretty much any other widely used dynamic language. If we should expose Vulkan bindings to dynamic languages (and why not?) JS is the obvious first choice for a target, given its speed and popularity. > JavaScript -> native transitions ain't cheap They're actually very cheap nowadays, because so many benchmarks stress the DOM and C++-implemented builtins. Driver calls, even with Vulkan, far exceed the cost of JS-to-native transitions. glDrawElements() is probably at least 100x slower than a JS-to-native call, the latter of which has latencies measured in nanoseconds. > Let me throw a GPU shader into a CSS3 transition animation or something like that, for example. Please, let's not. This will neither be good for designers (modern GPU programming has an enormous learning curve compared to CSS) nor browser developers (shaders would break batching and would expose too many engine-specific internal details).
  - pandaman 9y ago
    I don't think glDrawElements() goes into the driver though (at least there is no sane reason for it I can imagine, you only need to go into the driver to kick a command buffer at the end of frame). Nevertheless, even if some implementations actually do call driver, the GP's point is that the whole point of Vulkan is getting rid of global state to allow parallel command buffer creation. JS is single threaded so, no matter how cheap or expensive the calls are, you won't be able to take advantage of Vulkan since you are running just one thread.
    - nhaehnle 9y ago
      Of course glDrawElements() has to go into the driver, because it needs to do hardware-specific work. This is obviously true in OpenGL(ES), but even if you were to implement it via a translation layer to Vulkan, you still have to call the various Vulkan-equivalent commands, at the very least vkCmdDrawIndexed. Here's an implementation to make it painfully obvious why that has to involve the driver: https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6246833a2a2d5f034/src/amd/vulkan/radv_cmd_buffer.c#L2758 https://github.com/mesa3d/mesa/blob/d819b1fcec02be5e0cfc87b6...

Impossible 9y ago

Oculus Tiny Room is linked, but Valve also has a pretty good minimal Vulkan + OpenVR example in the OpenVR SDK called hellovr_vulkan (https://github.com/ValveSoftware/openvr/blob/master/samples/hellovr_vulkan/hellovr_vulkan_main.cpp https://github.com/ValveSoftware/openvr/blob/master/samples/...). On HN this might be attractive because people tend to complain about Windows only software, and all of Valve's samples use SDL and in theory run on Mac OS X and Linux. The OpenVR example is a little bit more verbose, but it does have some extra functionality, like drawing render models (controllers) provided by the API.

uep 9y ago
Thanks for this! I happen to have a Vive and have been wanting to get my game engine outputting to it. I am primarily focused on Linux.
- rocky1138 9y ago
  Can we see your engine?

Nimsical 9y ago

I clicked cause I thought it was about Star Trek. Always forget there's a library with that name.

sleavey 9y ago
Disappointed it's not on Khan Academy.
- majewsky 9y ago
  KKKKHHHHHAAAAAAANNN!
khedoros1 9y ago
> Always forget there's a library with that name. And that "Vulcan" is properly spelled with a "c" in Star Trek? (At least in English...I suppose it might be different in other languages).
fsiefken 9y ago
Yes, me too, I really love conlangs. For the Vulcan language see: http://www.vli-online.org/vlif.htm http://www.vli-online.org/vlif.htm https://scifi.stackexchange.com/questions/1453/how-realized-is-the-vulcan-language https://scifi.stackexchange.com/questions/1453/how-realized-...

alistproducer2 9y ago

Can someone give me a non-graphical use-case for learning Vulkan or just GPU-based programming in general? I've heard of hardware acceleration. Is it something like writing your routines in a language like Vulkan and offloading the computation to the GPU?

jeremiep 9y ago
Massive SIMD works great on the GPU. Compute shaders are already a non-graphical use-case on the GPU. You get high bandwidth but also high latency, so its best for a few large batches rather than lots of small batches. There is also overhead to uploading and downloading data to and from the GPU. So you want to save more time than you spend there.
kllrnohj 9y ago
The use cases for GPU compute are fairly narrow. You need something that is embarrassingly parallel and deals with almost nothing but floats. You also need something isolated enough that you're ok with paying the PCI-E bandwidth overhead to send it to the GPU & receive the results back from the GPU.
- deleted 9y ago
  [deleted]
- pcwalton 9y ago
  > You need something that…deals with almost nothing but floats. This hasn't been true for years. GPU integer compute is quite good these days.
  - kllrnohj 9y ago
    GPUs will handle ints just fine, but it's not what they are best at. They are best at fp32, and depending on the GPU the gap is rather substantial. The performance characteristics of integer ops is also kinda weird.
    - 9y ago

deleted 9y ago

[deleted]

Kiro 9y ago

> It reminds me of a lot of the attitudes surrounding C++ when I was first learning it-- yes, it's more lines of code, but that doesn't mean it can't be a fine place for a beginner to start learning. Sure, but Vulkan really feels like another level of complexity. OpenGL is simple in comparison.

ATsch 9y ago
Well, libraries and frameworks have solved problems like that before and probably will again.
- robotresearcher 9y ago
  Low level graphics programming is tough, specialist work. Imagine a relatively simple stateful API layer over the top of this stuff, widely adopted and with an open spec. We could call it the Open Graphics Library, or OpenGL for short.
  - kuschku 9y ago
    And a horribly painful codebase that is a horror to work with. Nowadays people are more comfortable with having objects that represent something, and executing operations on them, than having to bind an object to a global variable, execute a global procedure, and unbinding it.
    - robotresearcher 9y ago
      You think so? I think people like to call functions with comprehensible arguments. I don't agree that people like to bind an object to a global variable, execute a global procedure, and unbind it. Does that sound like the API of anyone's dreams? The binding and unbinding sounds like pure overhead to me. I understand that very high performance and easy API may not be achievable, but seriously, the modern graphics APIs are hard to love.
      - kuschku 9y ago

atemerev 9y ago

800 lines of code to render a triangle. OK. I understand the need of being explicit, but why not include some reasonable defaults? When you need that last drop of performance, you could opt out of those defaults, but specifying everything by hand... OK, OK, I understand. Perhaps Vulkan is a compiler target. It was never intended for someone to write Vulkan code by hand. Just code in some higher-level API or language and get everything compiled into low-level Vulkan calls. I surely hope so, for the sake of my sanity. Right? Right?

corysama 9y ago
It's not intended for someone to use Vulkan to render a triangle. If you want to render a triangle (or merely a million triangles), just throw together some simple OpenGL code and you'll have no problems assuming basic optimizations (large batches). If you really need Vulkan's advantages, you are committing yourself to a whole lot more than 800 lines of code, Vulkan or no. The setup code will be done once, then you'll move on to many thousands of lines of pipeline code that will take the vast majority of dev time. The GL vs Vulkan question is more about what you get in the end. GL takes care of a lot for you, but that makes writing a highly specialized pipeline more complicated. Vulkan makes everything complicated because specialization is presumed to be the goal.
- atemerev 9y ago
  Firstly, I am worried that OpenGL development seems to be stalled and it looks like its going into maintenance mode, where Vulkan is where all action happens. It is increasingly pushed as a replacement to OpenGL, implicitly or explicitly, and if it will be the only mainstream alternative, I am somewhat worried. Secondly, I am worried that there are no mid-level 3D graphic toolkits. We have low-level (very very low-level) like Vulkan, or high-level stuff like Three.js and game engines (which are not what I need, as I write realtime scientific visualization code). What I want is something like imgui (https://github.com/ocornut/imgui https://github.com/ocornut/imgui), but for 3D. Simple, powerful, and bloat-free. However, I can't find anything like this.
  - 9y ago