-
Notifications
You must be signed in to change notification settings - Fork 984
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
Add multiple render targets example (v2) #5313
Add multiple render targets example (v2) #5313
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, some small comments, then probably one more small scale review, and this can land!
use glam::Vec2; | ||
use std::borrow::Cow; | ||
use wgpu::{ | ||
Adapter, BindGroup, BindGroupLayout, ColorTargetState, CommandEncoder, Device, Extent3d, Queue, | ||
RenderPassColorAttachment, RenderPipeline, Sampler, ShaderModule, SurfaceConfiguration, | ||
Texture, TextureAspect, TextureDimension, TextureFormat, TextureUsages, TextureView, | ||
TextureViewDescriptor, TextureViewDimension, | ||
}; | ||
use winit::event::WindowEvent; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to be very annoying, and say we probably shouldn't import these names and always qualify with wgpu or the library they're from. It helps readability a ton when looking at a small section of code.
fn create_ball_texture_data(width: usize, height: usize) -> Vec<u8> { | ||
// Creates black and white pixel data for the texture to sample. | ||
let mut img_data = Vec::with_capacity(width * height); | ||
let center: Vec2 = Vec2::new(width as f32 * 0.5, height as f32 * 0.5); | ||
let half_distance = width as f32 * 0.5; | ||
for y in 0..width { | ||
for x in 0..height { | ||
let cur_pos = Vec2::new(x as f32, y as f32); | ||
let distance_to_center_normalized = | ||
1.0 - (cur_pos - center).length() / half_distance; | ||
let val: u8 = (u8::MAX as f32 * distance_to_center_normalized) as u8; | ||
img_data.push(val) | ||
} | ||
} | ||
img_data | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's make this a normal free function, not a nested one.
} | ||
} | ||
|
||
fn create_target_textures( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets make this a TextureTarget::new
and move it next to the definition of TextureTargets
multiview: None, | ||
}); | ||
|
||
let (ba, bb) = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let (ba, bb) = | |
let (bg_a, bg_b) = |
Or better yet bg_left bg_right.
@cwfitzgerald Your requested changes are now implemented. Let me know if there is anything else. |
I added another commit to make all the imports direct as I realized that is probably what you meant and not just the wgpu imports. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple issues with the screenshot and such. Additionally in general the code needs a lot more commentary about what's going on and why (adding things like method documentation would go a long way).
Additionally there seems the tests are failing inside the GL backend, we can mark it as failing to not block merging this, but should be filed as a follow up issue.
|
||
## Screenshots | ||
|
||
![Multi render target](./screenshot.png) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you run the tests locally with cargo xtask test
? The screenshot was never generated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The screenshot gets generated just fine for me, although bunch of tests fail on my machine overall. Do you want the generated screenshot to be part of the repository?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - the fact that the screenshot is generated is how we ensure the screenshot stays up to date with the example
#[wgpu_test::gpu_test] | ||
static TEST: crate::framework::ExampleTestParams = crate::framework::ExampleTestParams { | ||
name: EXAMPLE_NAME, | ||
// Generated on 1080ti on Vk/Windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These seem to just be blindly copied from other examples
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that a problem? Can you give me some guidance on how the test should be configured for this specific example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for the comments, I am not sure what should be commented better. The readme of the example describes what the example does and how it works. There are also various comments in the code. The render function has inline comments describing what the draw calls of the example do. Should these comments be on the methods instead?
Is the issue with GL failing something related to the internals of wgpu and not this example? If not, is there something I can do about it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that a problem? Can you give me some guidance on how the test should be configured for this specific example?
Basically the idea is that you'll start with the lowest possible tolerance, then increase it as you find issues on specific gpu/api combinations. In your case, this should be listed as whatever card you ran it on to generate the tolerance. This way we have a record of what device is keeping the limit high, so we can lower it if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for the comments, I am not sure what should be commented better. The readme of the example describes what the example does and how it works. There are also various comments in the code. The render function has inline comments describing what the draw calls of the example do. Should these comments be on the methods instead?
Let me give this another, better look
I don't think I did a very good job of reviewing this the first time around and giving actionable advice, so I'm going to give this another go. It also completely fell through the cracks of reviewing - sorry for all the trouble, we try to be more on top of things than this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, I have a few small comments, but I think this is largely ready to go! I've pushed a commit which fixes compilation issues that have happened in the interim.
Thanks for the patience :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice!
Hey, no worries. Better prioritize the library itself over examples first. I applied your suggested changes. Let me know what you think. Should the changelog addition be moved to next release or do we leave it under |
Nice!
The next release |
…example' into multiple_render_targets_example
Amazing, lets land this! |
Connections
This PR depends on #5312
This is a new version of #5297 which had some issues.
Description
This PR adds a new example that demonstrates how to use multiple render targets when you want to render to two or more targets from the fragment shader.
As far as I know, none of the existing examples demonstrate this, and furthermore, finding information about how to do this with wgpu seems to be way too challenging, or at least it was for me. I had to ask help from multiple people who knew how to do this, and before that I was not even sure if this was possible at all.
Testing
I am not sure if this should or can be tested, or if the core feature has already been tested. Suggestions or instructions are welcome on how to implement the required tests.
Checklist
cargo fmt
.cargo clippy
. If applicable, add:--target wasm32-unknown-unknown
--target wasm32-unknown-emscripten
cargo xtask test
to run tests.CHANGELOG.md
. See simple instructions inside file.