We, GFX Developers, constantly grow and evolve our understanding on how the library ecosystem should be structured. One idea that has been floating around for a while has now occupied the hearts and minds of the core team. The idea (see #1102) is that our lower layer should make no performance compromises and instead drop any safety guarantees. Let the higher level take care of resource lifetimes, command queues and memory heaps capabilities.

This is what a platform API is meant to be - an unsafe abstraction with a sole purpose of hiding the platform specifics behind a consistent API. Various frontends of that API will make different trade-offs between safety and performance. So that even Vulkano could become a frontend. A sound example is WebRender, which only needs a limited set of GPU capabilities, a few pipeline layouts, and can manage the resource lifetimes itself.

Welcome CoreLL (short of Core Low Level) - our new core layer. Notice the ll suffix on the libraries in the repository: corell, backend/vulkanll, backend/dx12ll, etc. The groundwork has been mostly done by msiglreith - our one-man army. JohnColanduoni contributed the Metal implementation, while I made D3D12 a reality. For some time, ll libraries co-existed with the regular ones covered by a single trianglell example, while @msiglreith worked hard to integrate them into the mainstream by porting gfx_render (known simply as gfx), gfx_app and all the examples to the new API. The work is far from being done yet (see a short overview here), but today we reached an important milestone - the first batch of integration changes is coming in this humongous PR.

Today can be marked on the calendar as the end of an era in GFX history. An era of us wondering around and looking for a true path and destiny of the project. It is clear now: we want to be the low-level GPU abstraction focused on current-gen graphics APIs (Vulkan, D3D12, Metal). We want to be the playground and implementation of GPUWeb initiative. We want to be visible and viable.

There is no way back. We are going to branch out the current code and support it, leaving a window for a few breaking changes in follow-up versions, but the main development is going to be done inside LL code. We need to finish the migration, remove the duality of libraries, and make the code robust and performance enough to compete with production-quality libraries like MoltenVK. If you have experience with graphics APIs, join us in the journey of realizing Rust’s real power of low-level abstraction.