Get the top HN stories in your inbox every day.
rossant
bsder
While better websites are nice, what people need is lots better sample code.
Everything Vulkan currently is contaminated with C++ Object-itis Global State which makes everything look like old-school OpenGL code in spite of the fact that's not the way anyone uses these modern APIs.
With Vulkan, especially, this is a real crime since the C API is incredibly well done. (This is especially infuriating in the case of the Vulkan Memory Allocator which requires C++).
For example, timeline semaphores in Vulkan simplify so much, yet very little of the sample code uses them because they are relatively new. Dynamic state, similarly. Subpasses need to die unless you are on mobile and are verifiably GPU performance bound.
pjmlp
I for one, am more that pleased that Khronos has finally joined the 21st century and started offering C++ bindings to their specifications.
fusslo
very cool! I've been using pyQtGraph for real-time data coming out of microcontrollers. learning to use it was an uphill struggle, and I can't imagine how difficult it must have been to make datoviz
The way I've been working with pyQtGraph, I have an object reading data from a serial port. That object parses the raw data and sends it to a buffer. The pyQtGraph runs in a separate thread, which consumes the buffer, generates a new frame, then displays that frame.
How does datovis handle real time data streaming? It seems like your digital signals example is similar
kaycebasques
What was unusable about the previous site?
(I'm a technical writer, not affiliated with Vulkan, just trying to get data points on what generally makes good / bad docs sites)
rossant
I think it was just a huge single HTML page spanning hundreds of pages, that took minutes to load and systematically crashed my browser.
pjmlp
Khronos also had to accept Vulkan is unsable for visualization folks, hence ANARI.
Have you looked into it?
dcow
I don’t know what the old site was like so maybe this is actually an improvement, but I find this site really difficult to use and possibly even broken.
First off it’s really weird to start with a page that links back to the main site and then explains how to navigate the site. If it’s not obvious how to use your nav bar then you’re off to a really bad start. The home page should describe Vulkan and give me enough info to figure out where I need to go next. It should not be a mini tutorial on how to navigate.
Further, when I click on Education from the home page for example, it doesn't go anywhere (scrolls to the top of the page). When I click on the Vulkan Proposals link, it goes to a one paragraph thing that says it’s a cross link and when I click the link it goes back to the homepage. I’m so confused. I’m using mobile right now maybe it’s not broken on desktop?
pjmlp
It was much worse and it could kill your browser given the way the HTML was organised.
It was a running joke that it was faster to search on the PDF documentation, than load the site.
Conscat
I have bad memories of waiting almost 2 minutes for docs to load in Firefox so I could read a single paragraph.
qwertox
So it used to be like Android's documentation is now?
randomNumber7
It's on purpose, so you get a feeling how it is to use vulcan /S
danielvaughn
As someone who's kinda hovered around graphics land but never really stepped foot into it, it's pretty difficult to determine what Vulkan represents. Is it going to replace OpenGL? If I'm going to start learning graphics for the first time, would it still be useful to start with OpenGL or should I just dive into Vulkan?
jameskilton
Vulkan, Metal, and DirectX 12 are lower-level graphics APIs that provide abstractions better suited towards the GPUs of today (big, big buffers of data, processed by shaders). These new APIs came about because OpenGL and DirectX have grown into handling too many things are are now themselves the source of many bottlenecks for pushing data to your GPU.
These APIs being lower level means they are harder to get into, you really have to understand how GPUs work to understand why these APIs are the way they are. If you want to know that then by all means, dive in! It's fascinating stuff, IMO.
To answer your specific question, yes, Vulkan is intended to replace OpenGL.
whstl
Good answer. I would add that, despite all of them being low-level, Metal is quite easier than the other two, and DirectX 12 is also easier than Vulkan, despite having very similar concepts and ideas. This is in part due to API decisions and differences in verbosity, in part due to the "easier" ones having less flexibility. If your ultimate goal is to master Vulkan, starting with another can help. Also: OpenGL and DirectX are easier than those 3.
If I were learning those APIs today, I would personally start with either OpenGL, Metal or DirectX 11 (or 12 if you're slightly braver). They can give someone lots of insights that one can use when learning Vulkan.
Like other people mentioned, WebGPU or WebGL are also more straightforward and a good starting point.
flohofwoe
The big advantage of not using OpenGL is that D3D11, D3D12 and Metal all have excellent validation layers which tell you exactly what's wrong when you mess something up. In OpenGL you're pretty much left alone, staring at that black screen.
Xcode and Visual Studio also have builtin graphics debuggers for Metal and D3D11 (not sure if the VS debugger also supports D3D12 though).
WCSTombs
Of those three, Vulkan is the only one that is cross platform, and the only one that natively targets Linux.
omoikane
Note that DirectX is left-handed, while OpenGL, Metal, and Vulkan are all right-handed. Other things that use right-handed coordinate system include Blender, Godot, and my physics textbook, so left-handed coordinate systems is something of a minor annoyance for me.
But then, Unreal Engine is left-handed, so maybe some people prefer that.
alexarnesen
If you are looking to dig into Metal, this site and book might be useful. I have no graphics background and found it accessible.
Metal By Example https://metalbyexample.com/
drawkbox
> WebGPU or WebGL are also more straightforward and a good starting point.
WebGL and WebGPU also show some of the difference in how rendering libraries have evolved. They used to be all "stateful" global state like OpenGL/OpenGL ES. WebGL followed that model as it was simple and needed for the time, but could have bugs if correct flags weren't set.
WebGPU and other newer rendering libraries (Vulkan, Metal, and Direct3D 12) are more "modern" in that they have almost no global state. They are also more raw and lower level and take a bit more to grok.
This is one of the best overviews of the differences between WebGL/WebGPU but also is similar to how OpenGL to Vulkan, Metal, and Direct3D 12 evolved.
https://webgpufundamentals.org/webgpu/lessons/webgpu-from-we...
> The biggest difference is WebGL is a stateful API and WebGPU is not. By that I mean in WebGL there is a bunch of global state. Which textures are currently bound, which buffers are currently bound, what the current program is, what the blending, depth, and stencil settings are. You set those states by calling various API functions like `gl.bindBuffer`, `gl.enable`, `gl.blendFunc`, etc…, and they stay what you set them globally until you change them to something else.
> By contrast, In WebGPU there is almost no global state. Instead, there are the concepts of a pipeline or render pipeline and a render pass which together effectively contain most of the state that was global in WebGL. Which textures, which attributes, which buffers, and all the various other settings. Any settings you don’t set have default values. You can’t modify a pipeline. Instead, you create them and after that they are immutable. If you want different settings you need to create another pipeline. render passes do have some state, but that state is local to the render pass.
> The second-biggest difference is that WebGPU is lower level than WebGL. In WebGL many things connect by names. For example, you declare a uniform in GLSL and you look up its location
> `loc = gl.getUniformLocation(program, 'nameOfUniform')`;
> Another example is varyings, in a vertex shader you use `varying vec2 v_texcoord` or `out vec2 v_texcoord` and in the fragment shader you declare the corresponding varying naming it `v_texcoord`. The good part of this is if you mistype the name you’ll get an error.
> WebGPU, on the other hand, everything is entirely connected by index or byte offset. You don’t create individual uniforms like WebGL, instead you declare uniform blocks (a structure that declares your uniforms). It’s then up to you to make sure you manually organize the data you pass to the shader to match that structure.
> Note: WebGL2 has the same concept, known as Uniform Blocks, but WebGL2 also had the concept of uniforms by name. And, even though individual fields in a WebGL2 Uniform Block needed to be set via byte offsets, (a) you could query WebGL2 for those offsets and (b) you could still look up the block locations themselves by name.
> In WebGPU on the other hand EVERYTHING is by byte offset or index (often called ‘location’) and there is no API to query them. That means it’s entirely up to you to keep those locations in sync and to manually compute byte offsets.
For a time, supporting four rendering engines did cause lots of work for game engines, much more integration and abstraction.
As OpenGL support fades at least one will drop off. I will miss it as I do still love OpenGL/WebGL. OpenGL and OpenGL ES / WebGL in particular opened up mobile/web gaming in ways never before possible. Prior to that you had Director (3D), Flash (Papervision/Away3D/etc), Silverlight and more recently `<canvas>`. Canvas is great for smaller games but you need raw power for rendering 3d and WebGL (almost a direct port of OpenGL ES) brought that and engines like three.js use that well. Mobile gaming became the biggest gaming market due to OpenGL ES and web games took a leap on WebGL, also apps, interactives and tools became faster rendered.
With GL, in many cases the global state is more simple, but to take advantage of GPUs and rendering lower level the innovations were needed. The naming to index/position based for instance is lower level and can also end up in bugs just as the global state in GL could. The benefit is performance and cleaner global state.
It is probably a good idea to learn OpenGL/WebGL as some of the concept in WebGPU/newer engines will be more clear, much of it was simpler with naming.
Narew
Vulkan and DirectX12 are really lower level than OpenGL. The API of Metal is high level and more beginner friendly. I really hope to have a Metal like API on top of Vulkan because currently vulkan can't replace OpenGL for beginner and simple visualisation but Metal can.
cyber_kinetist
I was one of the N people who decided to delve into Vulkan because of curiosity for low-level optimization... but hearing some news and rumors around the gamedev scene I wonder if I should have spent time elsewhere (like, studying CUDA instead). Note that I'm writing this as a hobbyist so if there are any professional folks feel free to comment on anything problematic...
Currently Vulkan and DX12 seem to be in a state of turmoil. The main assumption with the two low-level APIs are that you need to have a fully specified static list of configuration options to send to the GPU when you send render commands (I'm essentially talking about the Pipeline State Object) - which will aid in optimization since there's not any dynamic state for the GPU driver to wrangle with. However, many devs in the game industry has tried making performant renderers with this model and not many have succeeded, because if you see actual GPU usage patterns in game engines they do need some of the flexibility previously had in DX11 / OpenGL. Without this dynamism, as a rendering engineer you essentially need to do one of the two:
- Pre-build all combinations of PSOs to implement your shader effects (if you have three different options for your rendering with A, B, C possible states each then you need to prebuild all A * B * C combinations of PSOs)... which will become ridiculous later on.
- Create an automatic caching system that caches PSOs, so that the initial pipeline compilation will introduce some lag but later cached usage of the same PSOs will be fast. Now you have a much worse version of what DX11 / OpenGL was already doing behind the scenes... (unless you git gud and surpass the abilities of NVIDIA driver developers)
With this in mind and also the various difficulties with managing the complexity of the new APIs (such as synchronization)... the reality is that a DX11 backend will probably be more performant than a naively written DX12 / Vulkan engine, since it's really just hard to beat NVIDIA's ridiculously optimized DX11 drivers that they have spent ridiculous amounts of time and money on. Unless you have a world-class team like Unreal or the ID tech folks... it seems like a gargantuan task to do. (Even Unreal Engine 5 had problems with heavy stuttering that are now fixed... and I suspect the issues were with how DX12 / Vulkan works)
Nowadays the problem seems to be widely known in the industry, up to the point that both DX12 and Vulkan have introduced experimental extensions which provide alternatives to the PSO model:
- The initial attempt is Vulkan's VK_EXT_shader_object extension (basically "Vulkan without Pipelines": https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...) - which overhauls the API by introducing shader objects that you can dynamically link at runtime. Basically somewhere in the middle of DX11/OpenGL and DX12: give back some dynamism to the API, but not up to the point where the driver struggles to maintain performance because of it.
- Other attempts seem to resemble more closely towards Render Graphs, which was a strategy that various game engines have already implemented on top of DX12 / Vulkan / console APIs. (See https://logins.github.io/graphics/2021/05/31/RenderGraphs.ht... for a introduction). For example, DX12's Work Graph API as preview (https://devblogs.microsoft.com/directx/d3d12-work-graphs-pre...), or Vulkan's VK_AMDX_shader_enqueue extension (https://gpuopen.com/gpu-work-graphs-in-vulkan/)
But nonetheless, I think I should just wait touching these APIs until things have sorted out between GPU manufacturers and engine developers. (If I would start making a game engine from scratch for my indie game I would probably just use DX11.)
danielvaughn
Thanks, yeah I'm tempted to just dive into the lowest level. My linear algebra is almost non-existent, so I feel like I should review my math fundamentals first. But I'm not sure how relevant it is to understanding the rendering pipeline itself, or if the math comes in at the applied layer.
undefined
Grum9
[dead]
sylware
dota2 and cs2 do not even have an opengl backend anymore.
On my side, I am waiting valve to trash their 32bits legacy code and get a clean vulkan->CPU fallbacked steam client (discovered you cannot libdl libGL because of that pesky ELF static_tls flag). I'll get some old games running with XWayland(maybe, and I would need a drm/vulkan|cpu implementation), and my own wayland drm/vulkan(or CPU) compositor.
undefined
Permik
Have you tried running Mesa's lavapipe? It's a software vulkan backend that should already be able to fit your needs if I understood you correctly.
pjmlp
And LibGNM, NVN.
midnightclubbed
If you've not touched 3d graphics before start with OpenGL with a view to moving on to a modern API soon after.
OpenGL does a lot of work for you behind the scenes and abstracts away most of the memory management, state management and GPU/CPU synchronization. It lets you worry about 'what' you are rendering and handles a lot of the 'how' internally. Vulcan and its peers (DirectX12, Metal) assume the programmer knows best and requires you to do everything manually. You have more control that way but for a beginner it will swamp you with minutia and make it far more difficult to things up and running.
flohofwoe
Both APIs are not all that great, Vulkan has a steep learning curve and requires tons of boilerplate code to even get a triangle on screen, and OpenGL is 30 years of sediment layers all pressed into a single 3D API.
WebGPU is currently probably the best balance between:
- easy to learn
- easy to tinker with (in web browsers at least)
- modern concepts (close enough to Metal, Vulkan and D3D12 that what you learned carries over)
- platform-agnostic
If you are on Windows, D3D11 is also a good native option, as is Metal on macOS.
no_time
>WebGPU
A massive shame that it's more or less bolted to the Sodom and Gomorrah of modern software development (Browsers and JS). Atleast in mindshare for sure.
There appears to be a non browser implementation of WebGPU now looking into it, but I can't find anyone using it or attempting to use it in production
flohofwoe
There's standardized C API which is both implemented by Dawn and wgpu.rs:
https://github.com/webgpu-native/webgpu-headers/blob/main/we...
...and this standardized API would also enable other independent native implementations (and shader compilation aside, it's actually not in the realm of the impossible to write a WebGPU implementation from scratch with a small team or even alone).
There's even thought put into the API being extensible via 'struct chaining', this is how the native implementations also accept SPIRV shader bytecode instead of just WGSL shader source code.
pjmlp
Actually there is something great related to that.
Despite my usual rants on how they are outdated in regards to native APIs, there is a great plus for them, WebGL and WebGPU are the only 3D APIs designed from scratch for managed languages.
crthpl
dawn is the WebGPU backend in chromium, while wgpu is the WebGPU backend for firefox written in Rust. wgpu is seeing a lot of use in non-browser uses; there are some examples on their website.
Akronymus
> Vulkan has a steep learning curve and requires tons of boilerplate code to even get a triangle on screen
In regards to the boilerplate: Yes, for the first draw you require a lot, but after that, it quickly becomes almost neglible.
hajile
Hopefully, WebGPU will eat all its competition and we can finally have just one standard moving forward.
flohofwoe
Nah, competition is good :)
E.g. without Metal as example of what a modern user-friendly 3D API can look like, WebGPU would probably look very different, and not in a good way.
My personal hope is that the concept of a "3D API" will eventually disappear into compilers like Clang and GCC and their standard libs.
E.g. WebGPU has a pretty big API surface just for ensuring that the CPU-provided data is compatible with what the GPU expects, and any mismatches manifest as runtime errors, not compile-time errors.
Most of this API surface would simply disappear if the same compiler can see both the CPU and GPU side code, integrated into the same compilation process.
pjmlp
Good luck convincing console vendors.
auggierose
I would start with WebGPU. Gives you hands-on cross platform knowledge and good foundations. Can't hurt to also look into WebGL, as that is more mature and deployed everywhere.
Chabsff
Seconding the first recommendation. WebGPU is currently the sweet spot between classic and modern approaches.
Also, don't be fooled by the name. While WebGPU was designed for the web browser, there are already some solid native implementations (wgpu and Dawn), and can definitely fill in the same role as Vulkan/DX12/Metal for most casual usages.
adrian17
Note that wgpu, while mostly mirroring WebGPU (and being used to implement WebGPU in Firefox), doesn't have an identical API; WebGPU being the lowest common denominator* of the underlying low-level APIs, while wgpu offering some minor platform-dependent features on top of that. For exaple wgpu's PrimitiveState has an additional polygon_mode field (that can be used to easily draw wireframes) that doesn't have a WebGPU equivalent.
(* meaning, while simplified, it's also missing some convenience features sprinkled in the lower-level APIs. For example, from what I've seen, pipeline explosion is much harder to deal with here.)
Buttons840
https://webgpufundamentals.org/ is the best learning material I've found. I've been learning Rust's WGPU and I appreciate that the tutorial uses a different language and a slightly different API[0], it keeps me thinking instead of just copy/pasting.
I never learned OpenGL, but think I will have to eventually refer to some OpenGL material, because there's no WebGPU material except the spec and like 3 incomplete tutorials.
[0]: WebGPU is a JavaScript API, so Rust cannot implement it exactly, but it's very close.
pjmlp
Using WebGPU as native API, instead of a proper middleware, means only using 2015 hardware features, which I guess it is fine for casual stuff.
dyingkneepad
In practice a lot of Vulkan documents assume you already know GL! So for learning purposes, modern GL is probably best.
Start learning modern GL: if the Hello Triangle doesn't use 2 shaders you're not learning modern GL. Hello Triangle for GL requires about 80 lines of code, while Hello Triangle for Vulkan requires about 1000 lines of code.
I highly recommend learnopengl.com and vulkan-tutorial.com.
If you're going to write a simple game, it's probably better to stick with GL. If you're going to write a real complex engine, Vulkan is the only acceptable path these days. Gl deviates way too much from what the GPU does, so there's a lot of CPU overhead and synchronization choke-points. Vulkan is way similar to an actual GPU and gives you more power to uses the resources in the appropriate way.
Deukhoofd
Vulkan was designed to tackle several issues OpenGL had. For example, OpenGL does not do multithreading, while Vulkan is able to, and OpenGL has a single global state, while with Vulkan you're able to create multiple different command buffers to hold the state in. In general Vulkan is also a lot faster at rendering, as it's closer to modern GPUs in design.
While Vulkan has been slowly replacing OpenGL, it's also more complex than OpenGL is. This means that OpenGL is still great for many simple use-cases, as you won't be overwhelmed by the complexity that Vulkan can bring along with it.
indigoabstract
OpenGL is definitely easier to learn and use than Vulkan, but it's reached the end of life so it won't be updated anymore.
I'm not sure Vulkan can ever replace OpenGL since it's much more complex and low level.
I think a better option for a beginner would be to use a rendering library like bgfx, sokol_gfx or even facebook's igl, since you can learn the basic concepts of rendering triangles and not bother too much with all the minute rendering details.
One can get an idea of the complexity build-up of the current graphics APIs by measuring how much code it takes make a triangle show up on screen.
Compared to the OpenGL fixed function days, the required Vulkan setup code is massive.
SotCodeLaureate
> I'm going to start learning graphics for the first time
Vulkan is a quagmire of very low-level concepts, the danger of getting stuck in them and give up without learning anything is just too high.
At the same time making something with OpenGL that is more interesting than a simple rotating cube is not that difficult and you will get a lot of mid-level understanding - how rendering pipeline implemented and organized, what kind of task it is. "Porting" this knowledge to Vk is straightforward.
brianzelip
You might add the following CSS to perhaps improve the presentation of your header logo (which seems a little awkward aligned to the bottom of the navbar as I see it):
```css
.navbar-item > .navbar-item {
padding: 0;
}MayeulC
This seems to come from there: https://github.com/KhronosGroup/antora-ui-khronos/blob/e6d03...
This css seems shared across multiple sites, so I'd be afraid of breaking one of them if not introducing yet another class, though I am not sure where the HTML for the inclusion of this logo is generated from.
Edit: seems likes it comes from there: https://github.com/KhronosGroup/antora-ui-khronos/blob/e6d03...
panzi
Also:
footer.footer {
display: none;
}
sachahjkl
my thoughts exactly lol
ForkMeOnTinder
Can anyone recommend a good self-contained "hello triangle" example with SDL2 + Vulkan? Just yesterday I was trying to start a project, and I tried building the top 4 example repos on github but couldn't get any of them to compile without errors.
ozarker
This one's been around a long time. I used it when I started with Vulkan back around 2017/18? It uses glfw but I used sdl2 with it when I went through it. You'll just need to read some sdl2 documentation to get the window hooked up.
flohofwoe
Not SDL2, but GLFW has something like that under the tests/ directory:
https://github.com/glfw/glfw/blob/master/tests/triangle-vulk...
(yes it's over 2kloc for a triangle - that's Vulkan for you ;) but at least it's all in one file readable from top to bottom instead of being spread over a dozen obscure "helper classes")
tedunangst
Is all of it necessary, or is some of it extra verbose for the sake of being explicit? If you leave this blank do you get nothing?
.components =
{
.r = VK_COMPONENT_SWIZZLE_R,
.g = VK_COMPONENT_SWIZZLE_G,
.b = VK_COMPONENT_SWIZZLE_B,
.a = VK_COMPONENT_SWIZZLE_A,
},hmry
Nicely spotted actually, in that specific case leaving it blank will get you the exact same result. That's because the enum has VK_COMPONENT_SWIZZLE_IDENTITY = 0, and setting everything to IDENTITY is defined to result in exactly what you expect. (r = r, g = g, ...). You can read the spec here if you want to: https://registry.khronos.org/vulkan/specs/1.3-extensions/man...
Most things in Vulkan have reasonable defaults, fortunately. Still, it's best to code with the spec open on another monitor.
MayeulC
> yes it's over 2kloc for a triangle - that's Vulkan for you
My understanding is that VK_EXT_shader_object should make such examples simpler? https://www.khronos.org/blog/you-can-use-vulkan-without-pipe...
nightpool
Ah, yes, one readable file, top to bottom https://i.ibb.co/qdjct5K/Screenshot-20231011-095306.png
flohofwoe
That's SPIRV shader bytecode. Does Vulkan actually come with an integrated shader compiler these days? Otherwise there's not much one can do for a standalone sample like that.
andrewmcwatters
https://github.com/Planimeter/game-engine-3d/blob/main/src/g...
Try reading the above implementation. It’s a Hello, Triangle with SDL. Should compile out of the box on Windows.
raytopia
I'm still suprised that no one has made an equivalent of the old immediate mode graphics apis on top of the newer apis.
I know the old school way is very slow and limited but it's a lot more fun and easy to use then dealing with thousands of lines for a single triangle and plus by using the old school way you get to move onto other stuff instead of being stuck in the infinitely deep rabit hole of modern rendering.
lazypenguin
People have, for example https://www.raylib.com/
kllrnohj
There's plenty of abstraction libraries available including for example webgpu. Why do you want immediate mode specifically? It's not a very useful balance to strike between just using an actual 2d library vs. learning how shaders work which you're going to need for anything slightly non-trivial
pjmlp
Ah, way much better than it used to be.
Get the top HN stories in your inbox every day.
Nice, much better than the old website which was basically unusable.
I've been strongly attracted to Vulkan since it was announced in 2015. Being annoyed by the limitations of OpenGL for scientific visualizations, it seemed like a significant improvement. When the specification was released, I was both fascinated and terrified by its extreme complexity. I understood mostly nothing at first. I took it as a personal challenge to learn it and do something with it.
After dozens of times reading the documentation and experimenting with the code (tutorials were scarce at the time), I started to understand the most basic functionality. I spent much of the Covid lockdowns playing with Vulkan and developing prototypes of a scientific visualization library in C [1].
In the process, I wrote a thin wrapper in C on top of Vulkan to make it less painful to use [2]. It turns out this wrapper is quite similar to WebGPU. I'll explore interoperability avenues later.
Datoviz is still an experimental project. I'm actively working on the next version of Datoviz which I hope to release in a few months.
[1] https://cyrille.rossant.net/datoviz/
[2] https://datoviz.org/howto/standalone_vklite/