[HN Gopher] Vulkan Tutorial (Rust)
___________________________________________________________________
Vulkan Tutorial (Rust)
Author : ibobev
Score : 150 points
Date : 2023-01-12 16:30 UTC (6 hours ago)
(HTM) web link (kylemayes.github.io)
(TXT) w3m dump (kylemayes.github.io)
| adamnemecek wrote:
| If you are just getting into graphics, also consider checking out
| 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 wrote:
| 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.
| pjmlp wrote:
| Apple, Sony, Nintendo, Microsoft.
|
| Metal also predates the nice present of AMD's Mantle to
| Khronos, which otherwise would still be arguing today what
| OpenGL vNext would look like.
| pohl wrote:
| I believe the Metal project was underway for a couple years
| before the Vulkan project began.
| adamnemecek wrote:
| > 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 wrote:
| I would say Mantle jump started the new generation of GPU
| APIs. Not sure if it predates Metal's development.
| rendaw wrote:
| I assumed that that abstraction meant that you lost some of
| Vulkan's flexibility/features. Is this not the case?
| adamnemecek wrote:
| Yes, but wgpu is more than fine for 99% of use cases.
| davefol wrote:
| 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/
|
| 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.
| kevinskii wrote:
| 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
| higherhalf wrote:
| 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...
|
| [2]: https://github.com/DustinHLand/vkDOOM3
| andrewmcwatters wrote:
| 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.
| alphanullmeric wrote:
| >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.
|
| Seems like it'll be a perfect match for rust then
| kangalioo wrote:
| In my experience, the patterns Rust makes explicit are
| usually worth reconsidering and replacing. Further, it makes
| other common patterns more compact than in other languages:
| e.g. `std::fs::read()` vs the abomination with
| ByteInputStream and IOReader or whatever from Java, and I
| believe C++ makes it non-trivial either
| alphanullmeric wrote:
| I mean I'd rather use default parameters and named
| arguments then make a dozen enums or macros and structs to
| pass into a function. Look at polars and bevy, rust makes
| things hideous. It's a great language for writing rust and
| not actually making something.
| smallstepforman wrote:
| Developers have different use cases. I have a laptop with both
| an integrated and discrete GPU, and the primary app uses the
| discrete device, however the aux tools (scene editors) use the
| integrated device, best of both worlds and I'm grateful I have
| the option to choose the output device. Even legacy OpenGL
| allows this.
| andrewmcwatters wrote:
| That's a fair statement but realize most graphics programmers
| don't do this. Many will attempt to minimize redraw to reduce
| power consumption, but most are not going to profile power
| consumption and consider integrated usage to further reduce
| power draw.
| brundolf wrote:
| > 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)
| flohofwoe wrote:
| The yardstick Vulkan is measured against shouldn't be OpenGL
| but D3D11 and Metal (even though Metal and Vulkan share a lot
| of common ideas which have their roots in modern GPU
| architectures, Metal is a _lot_ more convenient to work with
| than Vulkan), and D3D10 /11 introduced many of those ideas to
| graphics programmers already (like grouping related render
| states into immutable state objects).
| flohofwoe wrote:
| > but many eg. game developers use a game engine like Unity
| or Unreal and never touch the raw API
|
| 3D APIs have a lot more uses than game development. Even
| though I'm also coming out of the game dev world and can
| understand the reasons, it _is_ a real shame that game engine
| rendering engineers had so much influence in the design of
| modern 3D APIs, because it 's hard to find a community that's
| more imprisoned in ivory towers of their own design ;)
| andrewmcwatters wrote:
| I do graphics programming for 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 wrote:
| 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.
| pjmlp wrote:
| Shaders as concept are older than IrisGL actually, one of
| the first famous examples.
|
| https://en.m.wikipedia.org/wiki/TMS34010
| jjtheblunt wrote:
| cool example!
| pjmlp wrote:
| I decided to contend myself with Web 3D APIs, even if I find
| them quite behind native ones, or stuff like Unreal/Unity when
| playing with native code.
|
| Without middleware I would rather stick to a proprietary API
| than deal with Vulkan.
| flohofwoe wrote:
| Vulkan is pretty close to proprietary too, after all it only
| really matters on Linux and Android ;)
| pjmlp wrote:
| Yeah, seen that way.
|
| Pity that it misses out on the tooling from the other SDKs.
| Zagitta wrote:
| Sane defaults tend to evolve over time with the hardware
| architectures so it's probably not a very good idea to encode
| these into the API.
|
| A lot of what you request can be achieved by using Vulkan
| wrappers that simplifies these things without making the driver
| API more magic/implicit and regress back to the dx9/openGL
| style API's that mantle/vulkan/dx12 was made in opposition of.
| andrewmcwatters wrote:
| I don't think Vulkan needs to specify hardware level
| defaults, but for instance, something all of the tutorials
| does is irrelevant: no one cares what your game engine
| information is. There's going to be a handful of major
| studios whose Vulkan metrics are going to be collected and
| vendors can study that data.
|
| 99% of tutorial readers are going to grab the first device
| exposed to them. On a system with a discrete GPU, which is
| what most people will want to use, they'll pick that. When
| it's not available, an integrated device will be exposed.
|
| You will almost never need to actually query for more device
| information.
|
| If you're working through a tutorial, you will almost never
| need to actually write your own validation layers.
|
| etc.
|
| Edit: A lot of these tutorials do things that you don't need
| to do simply because they read it from another tutorial! I
| seriously doubt everyone is actually reading the reference
| specification.
| thewebcount wrote:
| Yeah, this is easy to confirm. I've had a desktop with
| multiple GPUs in it for close to 10 years, and outside of
| Final Cut Pro and Motion, I haven't found a single app
| (definitely not any games) that would use both GPUs, even
| though they were there and waiting for data! I write my own
| code to use both of them and it screams. It's unfortunate
| that more developers don't use it. But it's certainly
| overkill for an intro tutorial to discuss it.
|
| All of this to say: I fully agree. The Vulkan tutorials
| I've found have put me off ever trying to use it again. I'm
| sticking to Metal which is much easier to understand and a
| delight to use.
| bashmelek wrote:
| I recently started that tutorial and this describes how I feel
| --thought it was just me being unready. The setup is very long
| and the explanation seems uneven oftentimes, such that getting
| an idea of what is going on and why has been challenging, to
| say the least. It is as though all of the setup and
| configuration is the point of the tutorial and Vulkan itself.
| John23832 wrote:
| 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?
___________________________________________________________________
(page generated 2023-01-12 23:01 UTC)