4 ms·

It's quite lean, it requires a lot less code than OpenGL does! But it does require some -- partly because there's some cruft left in the spec, but also because

It's quite lean, it requires a lot less code than OpenGL does! But it does require some -- partly because there's some cruft left in the spec, but also because there's always some work that can be shared. SPIR-V and NIR being the big ones, everyone needs a shader compiler, and a good chunk of the work around that can be shared. And then the stuff on top of that like pipeline caches. That's stuff where the spec got it right, but just everybody needs some infrastructure. There's also things like subpasses, which, if you can ignore it, you can just use a "default" implementation that acts like a desktop immediate-mode GPU and ignores subpasses. Not always appropriate for a mobile GPU or a tiler, where subpasses are meaningful to you, so it's provided as an optional helper. Then there's just leftover spec mistakes like VkFramebuffer, where the spec is just thicker than it should be. That's fixed in future spec versions but someone needs to implement the old way.

sylware 5y ago
VkFramebuffer is gone in future versions or vulkan? By what was it replaced? (I am being lazy here, asking instead of going to read the latest specs). I coded my everyday video player using vulkan (very conservative), I would move my code to this new thingy once it's in mesa. What I liked with vulkan, on the main thread of my video player, I just post vulkan non-blocking commands, I don't even need a video thread! I can even use the main thread to mix fast enough the audio data! NIR is a sweet spot for me (lean C89 code with benign bits of c99/c11), even though I would like a configure "switch" to remove all non-breaking algebraic optimizations from the vulkan drivers (I used to do that myself for a good while, near 0 performance impact) since it is redondant because those should be directly done in spir-v code. Since I am an AMD user (I play video games, now all the ones I play have a vulkan backend), even if I really dislike a bloody lot c++, I am grateful to valve for ACO (because llvm is beyond toxic, even from a c++ point of view). But I wish ACO would manage to add the possibility for hand-coded assembly shaders (AMDGPU ISA is public and really ez to code), just need a few relocation types (writing an assembler should not be a nightmare like with hw architectures using bazillions of relocation types).
- jamesfinlayson 5y ago
  Oh neat - I didn't realise ACO was even a thing.
- gpderetta 5y ago
  what's wrong with LLVM? Is this about the frequent breaking API changes?

sylware 5y ago

VkFramebuffer is gone in future versions or vulkan? By what was it replaced? (I am being lazy here, asking instead of going to read the latest specs). I coded my everyday video player using vulkan (very conservative), I would move my code to this new thingy once it's in mesa. What I liked with vulkan, on the main thread of my video player, I just post vulkan non-blocking commands, I don't even need a video thread! I can even use the main thread to mix fast enough the audio data! NIR is a sweet spot for me (lean C89 code with benign bits of c99/c11), even though I would like a configure "switch" to remove all non-breaking algebraic optimizations from the vulkan drivers (I used to do that myself for a good while, near 0 performance impact) since it is redondant because those should be directly done in spir-v code. Since I am an AMD user (I play video games, now all the ones I play have a vulkan backend), even if I really dislike a bloody lot c++, I am grateful to valve for ACO (because llvm is beyond toxic, even from a c++ point of view). But I wish ACO would manage to add the possibility for hand-coded assembly shaders (AMDGPU ISA is public and really ez to code), just need a few relocation types (writing an assembler should not be a nightmare like with hw architectures using bazillions of relocation types).

jamesfinlayson 5y ago
Oh neat - I didn't realise ACO was even a thing.
gpderetta 5y ago
what's wrong with LLVM? Is this about the frequent breaking API changes?