@tomaka it’s been a while, eh?
If I agreed with that I obviously wouldn’t work on vulkano.
That’s obviously false, since we do support multiple APIs, and you still work on
For me the idea of abstracting over multiple APIs is problematic per se.
Both Khronos and W3C disagree with you.
Since all APIs have differences, your library has to be higher-level than each of the graphical APIs that you abstract over.
Also false. Vulkan is lower than Metal, but Vulkan -> Metal has been proven by MoltenVK to translate somewhat efficiently (used in production).
After all if you could simply expose the same API for all the underlying graphical APIs, then there would be no point in having multiple graphical APIs in the first place.
Reasons for multiple native APIs are many, and not all of them are technical (read: some of them are purely political). Technology can be seen as a tool here to solve political problems even
The consequence is that Vulkan-only features such as multiple subpasses, secondary command buffers, having multiple buffers/images that alias in memory, transient images, etc. can’t be supported by a cross-API library.
Not all of the Vulkan features can be efficiently emulated, but one can take a useful subset and make it portable. That’s the goal of Vulkan Portability initiative.
How do you make use of that knowledge when you use a cross-API library that doesn’t expose the concept of memory heaps?
Interestingly, memory types/heaps model of Vulkan allows to encode some nasty foreign API differences nicely. For example, D3D12 resource heaps tier-1 are not allowed to mix buffers/images/targets. We enforce it by exposing multiple memory types and specifying them in memory requirements, so that the user can’t mix those resources if they fulfill the requirement. Another example is GL, where exposing multiple Vulkan memory types/heaps allows to communicate to the driver what CPU access we need. In other words, yes, other APIs have different concepts, but they still come down to the same hardware, and so can often be mapped nicely.
Meanwhile in a higher-level library function calls don’t necessarily map exactly to low-level functions, which makes following the flow of the program difficult.
Sure thing. There is another side of the story though - having multiple backends at your disposal opens more opportunity to debug an application. Something might be caught by Metal debug layer, something is easier to debug with PIX for Windows, etc.
I know that you will have to rewrite all shaders if you want to switch between OpenGL, DirectX and Vulkan.
That was in
pre-ll. Today though, we uniformly accept SPIRV code and generate the native platform shaders with SPIRV-Cross. The differences (e.g. coordinate systems) are taken into account during this translation, making shaders totally portable.
TL;DR: I encourage you to learn more about the current (and future) gfx-rs. We aren’t competitors, we are friends. After all, one of the goals is to link to