Nikita LisitsaFeb 20

I'm still mildly suspicious that some of my perf problems (esp. wrt multi draw indirect) are due to some mandatory wgpu validation and honestly I'm lowkey starting to think about rewriting the rendering in Vulkan :/

(and even disabling non-mandatory validation is kinda broken in wgpu-native, and my 3-months-old issue about it is still ignored 😢)

Or maybe try Dawn instead, that would be a saner option

Show threadEvvy 

@lisyarus if you're not targeting old gpus (or old drivers?), vulkan can even end up being a bit more convenient in certain aspects than wgpu

buffer device address, descriptor indexing, and the like

with dynamic rendering, push descriptors, and deciding not to care about image layouts, i feel the only difference really from wgpu is that you have to think a bit more about synchronization and texture uploads

you do have to type some boilerplate, and most importantly you need to figure out which 10% of the api surface you actually need  

can recommend reading through https://www.howtovulkan.com

How to Vulkan in 2026 - How to Vulkan

How to write Vulkan graphics code in 2026

Feb 20 at 9:20amWeb
Show threadAksel HjerpbakkFeb 20
@pierogiburo @lisyarus I second this. Modern vulkan is pleasant. Hard part is actually knowing the "correct" API in vulkan since the working group refuses to actually remove anything for backwards compatibility. Atleast the documentation has started to label some functions that are considered "deprecated".
Show threadrojunFeb 20

@avokado @pierogiburo @lisyarus I'm testing my assumptions and memory here, as I did try to hook #Vulkan to a framework at work about 2 years ago.

Afaik, despite the lot-of-typing, Vulkan also provides error cues for troubleshooting like nothing I've seen so far. Or are there better alternatives in regards of debugging? (Not talking about NVidia's or xcode's debuggers)

There's no other C++ native rendering framework that woud cater with a unified shader format without all the other connected bloat (like bgfx) now that Circle's effort was ditched. Right?

You can use modern ogl as the input for Vulkan though you'll depend on transpiling it to spirv and then to the platform specific format. I don't think this is an issue as I had an autoloading cmake job to handle this on file changes.

Macos is quite the divide here as the deprecated the ogl long ago and Metal, though it's quite good, is just different from DX.

To take into consideration, albeit this info is a bit dated, Khronos is not handling macos sdks itself, but used to delegate it to a subsidiary. Not sure if because of that, but the version of the standard that macos vulkan sdk provides might lag behind. I.e. macos might not provide the full feature set. Would make sense to check that before committing.

Show threadNikita LisitsaFeb 20
@rojun @avokado @pierogiburo Afaik MoltenVK is pretty decent (we're using it at work actually), but yeah, still need to check if everything I need works there
Show threadrojunFeb 20

@lisyarus @avokado @pierogiburo I just checked wikipedia and you're right, moltenvk has caught up with the standards.

Apparently not all Windows support further than 1.2, but I didn't look much into this.

Show threadAksel HjerpbakkFeb 20
@lisyarus @rojun @pierogiburo There is also a new driver on top of metal 4 called KosmicKrisp which hopefully will be even better when it matures (its only been in development for about a year)
Show threadradgeRaydenFeb 20
@pierogiburo @lisyarus also the recent descriptor heap extension shouldn't require newer hardware than what you'd already be using and takes over descriptor indexing.