pathfinder
pathfinder copied to clipboard
servo
Modernized GPU API
I tried porting the graphics part to wgpu-rs and faced the problem of the GPU API being still very GL-specific (no concept of command buffers, pipelines, pipeline layouts, etc). So this was a quick (unfinished!) attempt to evolve the GPU API first into something more suitable for WebGPU and other modern APIs.
Requesting feedback on the general direction, before I waste more time with it. At some level, I feel that re-inventing the GPU abstraction is a bad idea to begin with, given that we already have libraries specializing in that (gfx-hal, wgpu-rs) as well as Vulkan Portable.
One thing I wanted to do with pathfinder_gpu is to use only one trait and put all the methods on Device. This is because generic parameter lists tend to explode otherwise. Rust doesn't have a great solution for "trait families" like this.
Although hmm, I guess the "curiously recurring template pattern" you have there seems to work. I hadn't seen that before in Rust.
Does wgpu-rs work well on GL these days? At the time I wrote pathfinder_gpu wgpu-rs did not have good GL support. I'm also concerned about binary size and I don't want the dependency to become too heavyweight. Pathfinder's binary size is too large as it is. I'm open to switching to wgpu-rs if these issues are adequately addressed, though.
Looking at wgpu-rs, it looks like it's come a long way, so I'm definitely fine with moving over to it assuming the GL backend works well and the binary size doesn't become too big.
@pcwalton thanks for looking into it! I'm not too worried about GL backend shortcomings - if we discover some aspects of the backend don't work for pathfinder, we should be able to make the necessary changes promptly to make it work good.
What I am worried about is the abstraction level, at which the graphics in pathfinder would make most sense. wgpu-rs is tempting for sure, since it's would be easiest, most straightforward and closest to the current API. However, it wouldn't work well with the Szeged's fork of WebRender on gfx-hal, and we (the graphics team) would want to eventually run pathfinder there as well. Therefore, it seems better in the long run to invest into the gfx-hal port today (which @bzm3r has WIP), while also thinking of a best way to make it also available for apps written for wgpu-rs (see https://github.com/gfx-rs/wgpu-rs/issues/34) in the future.
I'm hesitant to switch to a low-level API while Pathfinder is still so unstable. For example, the sparse virtual texturing stuff I'm working on is a huge overhaul. It'll reduce productivity a lot to be using a low-level API. Eventually it may be appropriate to do that, though.
