-
-
Notifications
You must be signed in to change notification settings - Fork 809
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
wgpu-rs render backend #527
Conversation
68adc50
to
997aea8
Compare
…filing of wgpu renderer in external tools
0f2940d
to
9599b2d
Compare
I've done a basic look at optimising but unfortunately I think the render API needs to change to get any significant wins. I'll look into that after this PR. I'll count this as ready for review. |
wgpu would panic in this case, so filter out draws with < 3 indices.
Looks great, thanks! I still think there is some benefit to putting some common things in |
This will solve #14, at least for desktop. It's structured similarly to #520 with the renderer pulled out into its own subcrate.
This provides a wgpu-rs backend for rendering, that is completely agnostic to web or desktop. It could in theory be used today on web, provided your browser has support for it and someone hooks the thing up to web...
The API is extremely similar to Vulkan and isn't very suited to the way that we render today. After we pull this in, I'd like to change our renderer API to work on a frame object so that we only need to do one renderpass per frame and not unlimited per frame. I don't want this PR to break API of other renderers though (especially as #520 is still WIP).
This is still a work in progress, opening a draft PR so it's visible for anyone who wants to see, and to track remaining progress.
Remaining tasks: