Partially because Kvark, who has a long history in graphics programming, was enthusiastic about it, and has similar values of simplicity and effectiveness to our own. Mainly because our renderer is simple enough that we would have preferred to use Vulkan APIs directly, rather than going through wgpu. Blade is a thinner abstraction than wgpu, it's a bit more ergonomic than wgpu-hal, and it already supports our long term platform goals (Linux, Windows, and the web though via WebGL). So far, it's been running flawlessly, and it's been everything else that's the hard part!
wgpu (and webgpu more generally) is often presented as a very good choice for a cross platform low level graphics api. but it was designed around safety/security constraints to support the web, sometimes at the cost of performance (my understanding)
i heard somewhere this nice example: only big actors like AAA game engines would really benefit from the extra development effort it would take to use an even lower level api like vulkan/dx12 to squeeze the last 10% of performance that wgpu can't get you
so if i understand correctly, zed, just like a AAA game engine, wants to squeeze every last bit of performance from the gpu, and so wgpu is "too high level" for it? and blade is "like wgpu, but no design tradeoffs and lower level" so its a better fit? does that mean someday zed might reach for vulkan directly one day? im assuming dx12 is gonna be used on windows anyway?
Roughly yes, though I'd caveat it with the specific application of the GPU: simple, 2D, UI elements. We've already built an abstraction that allows us to fluently build up a design, and then burn it down into a collection of rectangles, paths, images, and such. We're not dealing with particle effects, lighting, 3D models, or anything else that game engines need to consider. As such, it's a lot lower cost for us to use something like Vulkan or DX12 directly. And, in fact, that was the backup plan if we didn't find something like Blade that we where happy with.
The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that. This is not a good thing on desktop.
> The "design of WebGPU" is a problem. It's designed for the web to be secure and sandboxed so the API design reflects that.
The page you linked clearly states that wgpu-hal's API is extremely unsafe and skips many checks in order to reduce overhead. So while "secure and sandboxed" explains why wgpu wasn't chosen, it doesn't explain why wgpu-hal wasn't chosen.