Skip to content
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

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Modernized GPU API #213

wants to merge 2 commits into from

Conversation

kvark
Copy link
Member

@kvark kvark commented Jul 7, 2019

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.

@kvark kvark requested a review from pcwalton July 7, 2019 02:18
@pcwalton
Copy link
Contributor

pcwalton commented Jul 7, 2019

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.

@pcwalton
Copy link
Contributor

pcwalton commented Jul 7, 2019

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.

@kvark kvark mentioned this pull request Jul 7, 2019
@pcwalton
Copy link
Contributor

pcwalton commented Jul 7, 2019

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.

@kvark
Copy link
Member Author

kvark commented Jul 8, 2019

@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 gfx-rs/wgpu-rs#34) in the future.

@pcwalton
Copy link
Contributor

pcwalton commented Jul 8, 2019

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.

@floppyhammer
Copy link
Contributor

Are you still working on this?

@jdm
Copy link
Member

jdm commented Feb 3, 2023

Nobody is actively working on Pathfinder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants