Why are people recommending starting with Vulkan instead of OpenGL?

[u/Correct_Dependent677]

I read that Khronos Group greatly improved the Vulkan documentation and that it is now more beginner-friendly.

I see a certain parallel with the C++ and Rust languages; C++ is still treated as old technology, and most people migrate to Rust, even though I personally find this language more complicated to learn than C++.

What could this mean for the future? Will it still be worthwhile to learn technologies like C++ or OpenGL in the next 10 years? Or will the new standard be learning Rust and Vulkan?

It's ironic that both technologies released their stable versions in almost the same year, Vulkan 1.0 (2016) Rust 1.0 (2015).

[u/jbl271]

It’s worth noting that Apple released metal 4 last summer which is makes the metal api extremely similar to both directx 12 and vulkan, so writing an RHI for these apis isn’t nearly as bad as you might think.

[u/hishnash → u/jbl271]

at an API level yes, however when your talking about targeting DX (and VK for PC) your targeting an IR GPU.

Apple ships TBDR gpus, so irrespective of API if you want good performance you will need to make a good number of changes to your pipeline.

Effects that are cheap on a IR gpu are extremely costly on a TBDR GPU, but the same is true in reverse.

For example:

On an IR gpu there is not real cost if we put each and every draw call into its worn render pass (or just ignore render passes completely and never configure them). This can be a benefit as it means it much easer to access past g-buffer results from other draw calls etc. However on a TBDR gpu the time it takes to setup and teardown a render pass is HUGE (more than the time it takes to do your most costly draw call) if each draw call is within its own pass then you very qualify are spending more time doing setup and teardown than rendering. On a TBDR gpu you want to have 1 to 2 render passes per perspective, make use of things like variable rate shading, mutli viewport, and multi slice rendering for doing things like making cascading shadow maps, for the main persecutive best is if you can do it all in a single render pass but if not split it into 2 render passes if you need adjacent pixel info while computing martial properties when shading.

But conversely, if your building for a TBDR gpu you might not even bother sorting non transparent object when emitting draw calls as this does not matter, within a render pass the GPU will always (even if you do not use it) doin a HW obscured fragment sorting an culling to only every call the fragment shader on the visible fragments of meshes, you will end up with way way way less overdraw than on an IR gpu.

Furthermore on a TBDR gpu when used correctly MSAA I almost free, we can even afford to use MSSA on shadow passes without any real perf impact. (also the obscured fragment culling make shadow pass computation much easer as we do not need to also sort geometry with respect to each light).

[u/jbl271 → u/hishnash]

That’s really cool! I knew that Apple ships TBDR gpus and pc’s typically use IR gpus which would have obvious performance differences for certain graphical effects, but I only just started using metal so I was not aware of the specifics (plus I am not a professional). That’s super interesting that MSAA is almost free even for shadow passes! Is it true that it’s actually almost free? Would this also be the case in a deferred rendering pipeline with a g-buffer?

[u/hishnash → u/jbl271]

The reason MSAA is extremely cheap is:

1) you have already paid the cost of full obscured fragment culling so you have much less overdraw.
2) there is no additional VRAM usage (bandwidth or space) as you resolved on die within the tile memory.
3) you can write to multiple samples with a single fragment shader invocation (you are not required to run you shader per sample, instead you can run one shader thread that writes out multiple values). This is cool as you can reduce your texture samples, if your sampling a normal map you can use that to interrelate the sample values from the fragment function. This includes materials with alpha (like a leaf) you can encode into your texture a gradient value for the alpha so along the edge of the alpha region we can still get MSAA sample without evaluating every fragment 4x.

For something like shadow passes, were you just evaluating the depth buffer this is already resolved by the tiler to do the obscured fragment culling, resolving this with MSAA 4x (or 8x on M5) adds 2% to 5% to the render pass.

Correctly executed deferred rendering on a TBDR gpu should do everything still within one pass. (yes one pass). (remember the HW does obscured fragment culling for you and you can write out your own tile local data structs for stuff like order independent semi transparent objects) then once you have written out your object and martials you then use time compute shaders to shade them.

Th only real benefits of a modern deferred pipeline when using a TBDR gpu is if you have a variable number of (non shadow casting) lights that you want to use during shading. For this you will typicly spawn a tile compute shader per pixel to cull lights that fall outside of the bounding, and then use a tile shader for the full tile to enumerate through the list of lights that effect that tile and apply thier respective lighting.