4 ms·

Vulkan Tutorial (Rust)

180 points by ibobev 4y ago

John23832 4y ago
When it's Rust, I upvote. But to the point, would this open OpenGL with Rust libs to be a new entry in the ML development space?
andrewmcwatters 4y ago
I'm glad that other people are still working on Vulkan documentation materials. Outside of just reading the specification, Overv's vulkan-tutorial.com is probably one of the most read Vulkan implementations in C++, but I have some minor complaints about it. And I hope this author considers making an improved tutorial, not just translating Overv's to Rust. Vulkan is so painfully verbose in unnecessary ways, forcing you to be explicit about everything, when in many cases, whole swaths of lines of code are unnecessary or the standard could have established sane defaults that match what actually happens in practice in the industry. Maybe I'm in the minority here, I'm sure I probably am, but I see no reason to declare particular structures in both the standard and in tutorial documentation like vulkan-tutorial.com when they widely aren't going to be of use to anyone until you reach broad adoption or advanced usage. Most of these tutorials should be helping you get to a triangle as fast as possible, but none of them follow the order of what you're exposed to in the reference material, and they all go on tangents about needing to state application info (not required), creating your own validation layers (this is advanced material, why recreate VK_LAYER_KHRONOS_validation???) or declare what device you're going to use (it's almost always going to be the first exposed device--even systems with discrete GPUs will only declare that they have one GPU available and hide the fact that they have an integrated GPU on the CPU). It leads to hundreds of lines of code that distract from the high-level goals: initialize the renderer, set your shaders, upload assets to the GPU, and draw them. I think the industry is still lacking reference-quality documentation outside of the reference specification, which doesn't explicitly help you with implementation details for the most common use cases. I wouldn't expect it to, but it would have been nice. A lot of modern reference specifications do actually do this now.
- brundolf 4y ago
  > Vulkan is so painfully verbose in unnecessary ways, forcing you to be explicit about everything It's my understanding that Vulkan (like Metal) has fundamentally different goals than OpenGL OpenGL is like if the lowest-level programming language available on your OS was Java. Low-enough level to be fast-enough most of the time, and high-enough level to write application code with. When OpenGL was designed, it was common for eg. game developers to directly write OpenGL code as a part of their game In today's world- we not only have higher-level libraries and APIs, but many eg. game developers use a game engine like Unity or Unreal and never touch the raw API. In this world, it makes sense to have that raw API be lower-level, so that the people maintaining the libraries and game engines can have more control and optimize those more deeply. Vulkan is the C to OpenGL's Java (that's my understanding anyway; I've never been paid to do graphics programming)
  - andrewmcwatters 4y ago
    I do graphics programming for Planimeter (https://github.com/Planimeter https://github.com/Planimeter). Even when you use game engines, you still actually have to understand some OpenGL/Vulkan/DirectX/Metal level details. If you understand one of the standards, the knowledge carries over to others. Most game engines will abstract away shader attributes, but if you're not aware of how to define them, you're probably not writing them, either. So even if you're not touching glGetAttribLocation/vertex attribute APIs, you still actually have to know how to use them. Otherwise, the assumption is that you're only ever going to be able to use basic predefined rendering information exposed from the host game engine. There's a bunch of other information like that which you have to be somewhat aware of once you step outside the bounds of "just draw this for me" with the host's default shaders.
  - jjtheblunt 4y ago
    OpenGL was an api cleanup of SGI IrisGL, a library wrapping configuration of their custom high performance graphics hardware. When the hardware techniques subsequently became more sophisticated and in particular programmable, so called shaders were a driving force in these more abstracted apis.
kevinskii 4y ago
Slightly tangential, but for those who have gone through vulkan-tutorial.com and still felt lost even knowing a bit about basic graphics programming concepts, I highly recommend Brendan Galea's Youtube video series on Vulkan [1]. I'm about halfway through it and so far it has really tied together a lot of different concepts and cleared up a lot of my lingering confusion. [1] https://www.youtube.com/@BrendanGalea/videos https://www.youtube.com/@BrendanGalea/videos
- higherhalf 4y ago
  For me, it was the "I Am Graphics And So Can You" [1] series, where author progresses from the similar concepts up to a working renderer for DOOM 3, linked in the intro of this article [2]. [1]: https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and-so-can-you-part-1 https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and... [2]: https://github.com/DustinHLand/vkDOOM3 https://github.com/DustinHLand/vkDOOM3
adamnemecek 4y ago
If you are just getting into graphics, also consider checking out wgpu https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu the Rust implementation of the WebGPU standard. Conceptually it's the same as Vulkan it's just a lot less pain in the ass to work with.
- Animats 4y ago
  Yes, that's one level up from Vulkan. You get abstraction over Vulkan, Apple's Metal (Apple just had to be different), and DX12, although Windows land supports Vulkan. Plus WebGL and Android support. Big win.
  - pohl 4y ago
    I believe the Metal project was underway for a couple years before the Vulkan project began.
  - adamnemecek 4y ago
    > Apple's Metal (Apple just had to be different) In their defense, Metal predates Vulkan by a couple of years and I would say that Metal jump started the new generation of GPU APIs.
    - cmovq 4y ago
      I would say Mantle jump started the new generation of GPU APIs. Not sure if it predates Metal’s development.
      - izacus 4y ago
        That sounds like typical Apple fan rewriting of history to me. Metal was barely relevant to any 3D acceleration conversation at the time the Mandle/VK/DX12 conversations and planning was being had. Apple platforms just weren't all that important for this industry and console experience from Xbox 360/PS3/Nintendo shaped requirements much more.
  - 4y ago
davefol 4y ago
I have spent the last week working on an off screen rendering tool using Vulkan and Rust. I’d highly recommend using vulkano https://vulkano.rs/ https://vulkano.rs/ It’s not stable but it’s useable. It’s actively developed. It’s quite a joy to use actually, feels like a rust library rather than a bunch of foreign function calls.

180 points by ibobev 4y ago

When it's Rust, I upvote. But to the point, would this open OpenGL with Rust libs to be a new entry in the ML development space?

andrewmcwatters 4y ago

I'm glad that other people are still working on Vulkan documentation materials. Outside of just reading the specification, Overv's vulkan-tutorial.com is probably one of the most read Vulkan implementations in C++, but I have some minor complaints about it. And I hope this author considers making an improved tutorial, not just translating Overv's to Rust. Vulkan is so painfully verbose in unnecessary ways, forcing you to be explicit about everything, when in many cases, whole swaths of lines of code are unnecessary or the standard could have established sane defaults that match what actually happens in practice in the industry. Maybe I'm in the minority here, I'm sure I probably am, but I see no reason to declare particular structures in both the standard and in tutorial documentation like vulkan-tutorial.com when they widely aren't going to be of use to anyone until you reach broad adoption or advanced usage. Most of these tutorials should be helping you get to a triangle as fast as possible, but none of them follow the order of what you're exposed to in the reference material, and they all go on tangents about needing to state application info (not required), creating your own validation layers (this is advanced material, why recreate VK_LAYER_KHRONOS_validation???) or declare what device you're going to use (it's almost always going to be the first exposed device--even systems with discrete GPUs will only declare that they have one GPU available and hide the fact that they have an integrated GPU on the CPU). It leads to hundreds of lines of code that distract from the high-level goals: initialize the renderer, set your shaders, upload assets to the GPU, and draw them. I think the industry is still lacking reference-quality documentation outside of the reference specification, which doesn't explicitly help you with implementation details for the most common use cases. I wouldn't expect it to, but it would have been nice. A lot of modern reference specifications do actually do this now.

brundolf 4y ago
> Vulkan is so painfully verbose in unnecessary ways, forcing you to be explicit about everything It's my understanding that Vulkan (like Metal) has fundamentally different goals than OpenGL OpenGL is like if the lowest-level programming language available on your OS was Java. Low-enough level to be fast-enough most of the time, and high-enough level to write application code with. When OpenGL was designed, it was common for eg. game developers to directly write OpenGL code as a part of their game In today's world- we not only have higher-level libraries and APIs, but many eg. game developers use a game engine like Unity or Unreal and never touch the raw API. In this world, it makes sense to have that raw API be lower-level, so that the people maintaining the libraries and game engines can have more control and optimize those more deeply. Vulkan is the C to OpenGL's Java (that's my understanding anyway; I've never been paid to do graphics programming)
- andrewmcwatters 4y ago
  I do graphics programming for Planimeter (https://github.com/Planimeter https://github.com/Planimeter). Even when you use game engines, you still actually have to understand some OpenGL/Vulkan/DirectX/Metal level details. If you understand one of the standards, the knowledge carries over to others. Most game engines will abstract away shader attributes, but if you're not aware of how to define them, you're probably not writing them, either. So even if you're not touching glGetAttribLocation/vertex attribute APIs, you still actually have to know how to use them. Otherwise, the assumption is that you're only ever going to be able to use basic predefined rendering information exposed from the host game engine. There's a bunch of other information like that which you have to be somewhat aware of once you step outside the bounds of "just draw this for me" with the host's default shaders.
- jjtheblunt 4y ago
  OpenGL was an api cleanup of SGI IrisGL, a library wrapping configuration of their custom high performance graphics hardware. When the hardware techniques subsequently became more sophisticated and in particular programmable, so called shaders were a driving force in these more abstracted apis.

kevinskii 4y ago

Slightly tangential, but for those who have gone through vulkan-tutorial.com and still felt lost even knowing a bit about basic graphics programming concepts, I highly recommend Brendan Galea's Youtube video series on Vulkan [1]. I'm about halfway through it and so far it has really tied together a lot of different concepts and cleared up a lot of my lingering confusion. [1] https://www.youtube.com/@BrendanGalea/videos https://www.youtube.com/@BrendanGalea/videos

higherhalf 4y ago
For me, it was the "I Am Graphics And So Can You" [1] series, where author progresses from the similar concepts up to a working renderer for DOOM 3, linked in the intro of this article [2]. [1]: https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and-so-can-you-part-1 https://www.fasterthan.life/blog/2017/7/11/i-am-graphics-and... [2]: https://github.com/DustinHLand/vkDOOM3 https://github.com/DustinHLand/vkDOOM3

adamnemecek 4y ago

If you are just getting into graphics, also consider checking out wgpu https://github.com/gfx-rs/wgpu https://github.com/gfx-rs/wgpu the Rust implementation of the WebGPU standard. Conceptually it's the same as Vulkan it's just a lot less pain in the ass to work with.

Animats 4y ago
Yes, that's one level up from Vulkan. You get abstraction over Vulkan, Apple's Metal (Apple just had to be different), and DX12, although Windows land supports Vulkan. Plus WebGL and Android support. Big win.
- pohl 4y ago
  I believe the Metal project was underway for a couple years before the Vulkan project began.
- adamnemecek 4y ago
  > Apple's Metal (Apple just had to be different) In their defense, Metal predates Vulkan by a couple of years and I would say that Metal jump started the new generation of GPU APIs.
  - cmovq 4y ago
    I would say Mantle jump started the new generation of GPU APIs. Not sure if it predates Metal’s development.
    - izacus 4y ago
      That sounds like typical Apple fan rewriting of history to me. Metal was barely relevant to any 3D acceleration conversation at the time the Mandle/VK/DX12 conversations and planning was being had. Apple platforms just weren't all that important for this industry and console experience from Xbox 360/PS3/Nintendo shaped requirements much more.
- 4y ago

davefol 4y ago

I have spent the last week working on an off screen rendering tool using Vulkan and Rust. I’d highly recommend using vulkano https://vulkano.rs/ https://vulkano.rs/ It’s not stable but it’s useable. It’s actively developed. It’s quite a joy to use actually, feels like a rust library rather than a bunch of foreign function calls.