It came up in another thread, but I wanted to talk specifically about this notion.
Vulkan is a very low-level API. And while it will probably be useful in that regard, not everyone really needs that low-level nature. On the other hand, because Vulkan is so low-level, Vulkan drivers won’t be making very many decisions. So their behavior will be generally predictable, with far fewer of the bugs that plague, for example, OpenGL implementations.
So Vulkan makes for a good API to build other “higher-level-but-still-not-scene-graph-level” graphics APIs out of. This is similar to how SPIR-V works as a language that you build other languages to compile to,. The language you make could be Java, C#, Python, or even Fortran. Or it could be a simple, low-level SPIR-V “assembly” language that abstracts away register assignment and type declarations, but nothing more than that.
So here are some possibilities I was considering:
Yes, really. Of the 4 “next-gen” graphics APIs, it is the only one I would consider to not be derived specifically from Mantle. It doesn’t Mantle-style descriptor sets for one. But more importantly, it acts at a higher level of abstraction. It’s still well below OpenGL; it has explicit command queues, buffers, and its very much asynchronous.
But it manages memory for objects in an OpenGL fashion. Metal memory objects are inexorably tied to the uses of that memory; buffers and texture own their memory rather than rent them. Metal has no DMA queue or equivalent. It certainly has nothing like Mantle’s complex memory state system. In short, Metal abstracts memory resources much more than Mantle/D3D12/Vulkan.
And that makes the API much easier to use, for those for whom Vulkan-like memory management is nothing more than an annoyance.
Plus, since Metal is an actual API that would be independent of a Metal-on-Vulkan implementation, there’s more incentive to use a Vulkan implementation. Plus, because Metal’s abstractions are mostly identical to Vulkan’s, you’d be unlikely to lose any significant performance from it.
The downside of course is that Metal is an Objective-C interface. So you’d either be writing a C+±ified version of it, or you’d limit yourself and your users to Objective-C.
You’d also need a Metal Shading Language to SPIR-V compiler.
I mentioned this idea in the other thread, but this bears some discussion. The idea is to take modern OpenGL (plus potential changes in 4.6/5.0/whatever the next version is) and strip out all of the redundant stuff (non-DSA object modification and querying). Also, take out things that are hard to implement or are potentially slow (such as forcing the driver to take arbitrary pixel formats).
What you’d be left with would be a solid, reasonable API.
One nice thing about this is that, since it’s OpenGL minus stuff, it would still be backwards compatible with a full OpenGL implementation. So if performance is something you need, you could avoid the likely weak performance from a Vulkan implementation and go with a full OpenGL driver. But on the plus side, if performance is not a primary concern for you, then the fact that it’d be an open source project means that you can fix bugs in it at your leisure.
You could even go in and make changes to improve performance for your particular application.
This was the “nicer, cleaner” OpenGL API that the ARB attempted to invent before 2008. Writing it would be interesting from some standpoint. It would be a clean, cross-platform, immediate-mode-style API.
The downside here is that Longs Peak never existed as an API. The only “documentation” on it are some preliminary PDFs with some basic examples of how to construct objects. As such, even if someone liked using it, it would be functionally no different from you creating your own API.
So why limit yourself to Longs Peak, when you could potentially go even farther? Like not basing the API on C, for example. Or giving it explicit command buffers, ala NV_command_list. Once you’ve stopped limiting yourself to APIs that currently exist, why restrict yourself to OpenGL-style APIs?
So what kind of API would make for a useful abstraction above Vulkan, but is still lower level than a real scene graph? What ideas do you have?