WGPU (WebGPU/Vulkan/Metal etc) renderer#112
Draft
ArcturusEmrys wants to merge 36 commits intoInochi2D:mainfrom
Draft
WGPU (WebGPU/Vulkan/Metal etc) renderer#112ArcturusEmrys wants to merge 36 commits intoInochi2D:mainfrom
ArcturusEmrys wants to merge 36 commits intoInochi2D:mainfrom
Conversation
This necessitates newer GLSL shaders that use explicit uniform blocks and other things not in use in the OpenGL version of these shaders. They may be copied back to their OpenGL versions in the future.
I've decided to make the convention call that the vertex shader is always in slot 0, and the fragment shader in slot 1. More advanced build scripts and codegen would allow other configurations of the shaders, but I'm not sure if that time is justified just for this project.
This one isn't code-genned, but if I wind up needing variadic parameters or whatever it might wind up being so in the future.
Already, I've had to add methods to InoxRenderer and make a few take &mut instead of &. I suspect I will be completely revising InoxRenderer by the end of this.
I originally considered making this a normal array, but the const generics threatened to spill over to the entire program. Instead, we have an associated type which acts like an array and expected to be one.
…ven pipeline. The OpenGL renderer just assumes we can change these options on the fly, which isn't how modern GPUs work. I suspect it might have been easier to ubershader this, but I didn't want to change the shader code too much. Even with all 24 possible pipeline combinations compiling this shouldn't be too much of a drag on performance.
…o execute with color writes disabled.
OpenGL muddied the naming a bit but WGPU / vulkan etc are pretty clear
The GBuffer type is only intended to be rendered to for Composite nodes. I'm still not sure how emissive/bump works outside of Composite nodes - the OpenGL renderer renders straight to the window surface without binding any other textures. I may have to experiment...
Member
|
I'd love to have a WGPU renderer back, but I don't know WGPU myself. We had one previously but I ended up removing it because I couldn't maintain it. If you want this merged I'd want you to commit to maintaining at least the renderer. Though that's contingent on me maintaining inox2d itself, which I'm not really doing right now, so... |
Contributor
Author
|
I wasn't aware you'd had a wgpu renderer in the past. Would you be OK with me just PRing the |
Member
|
a33c92e FYI.
Sure! |
Contributor
Author
|
@Speykious #115 contains all the trait changes necessary for rendering |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds a renderer using wgpu, allowing the use of modern graphics APIs.
Due to requirements on the wgpu side, the
InoxRenderertrait has been significantly modified. All methods now take&mut selfandon_begin_draw/on_end_drawhave been moved into the trait proper.(I also anticipate potentially splitting out all the individual draw methods into a separate
InoxRendererDrawtrait that is returned fromon_begin_drawas it works better for wgpu. Currently, we have to unwrap/take stuff inInoxRendererthat could just be owned by the individual draw operation until done.)This also includes wgpu-compatible versions of all the OpenGL shaders. While it would technically be possible to share the shaders between renderers, it would impact the OpenGL side. (Specifically, everything has to use explicit layout and uniform blocks, and I increased the GLSL version to support this.) There is additionally a build script that precompiles all GLSL to SPIR-V and generates Rust code for bindings. That is necessary in wgpu as all the GLSL introspection in OpenGL is gone. I am not aware of a Rust library that can do this codegen, but there should be (and it'd probably be more generic than mine).
There's also an example app that uses the wgpu renderer.
This PR is NOT complete yet, as I have yet to get my model to work properly in inox2d in general before comparison testing the two.