Conversation
|
One thing I wanted to do with |
|
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 |
|
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! 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 gfx-rs/wgpu-rs#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. |
|
Are you still working on this? |
|
Nobody is actively working on Pathfinder. |
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.