-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modernized GPU API #213
base: main
Are you sure you want to change the base?
Modernized GPU API #213
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.