For people wondering what the point of this API is, my hopes/predictions for the API would include:
• a more 'stateless' API, where different threads can all produce independent command buffers, with no state leakage between them. Muti-core graphics submission can be implemented entirely by the user.
• a focus on command buffers as the main primitive. Much like network programming, where you're writing packets into buffers. The mapping between 'calls' and 'packets'/bytes being explicit.
• still having validation and virtual memory so user-code cant corrupt/crash the OS or other apps.
• user-mode access to GPU RAM. The ability to malloc/free GPU RAM. When you create a resource such as a buffer or texture, you'll be able to specify the memory location to be used.
• fine grained synchronization primitives to make the GPU wait on CPU jobs, and vice versa.
• an offline version of the API, where you can make graphics calls ahead of time, producing a command buffer that can be saved to disc.
• full support for aliasing resources, e.g. Creating a vertex buffer and a 2D texure and a render-target at the same memory address.
• explicit allocation and control of render-target companion/meta-data, such as Hi-Z, fast-clear and MSAA compression buffers.
• a shader compiler specific able to precompile ready-to-use binaries.
This is my dream...