-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[Merged by Bors] - Add main_texture_other #7343
[Merged by Bors] - Add main_texture_other #7343
Conversation
Signed-off-by: Torstein Grindvik <torstein.grindvik@nordicsemi.no>
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 changes make sense and do seem useful. I'm not sure about the other
terminology though. Unfortunately I can't think of something better
I'm confused on how this would work. During the prepare render stage, when creating bind groups, you won't know which texture will be the last written to, so you can't bind that as read. For instance, given nodes A -> B, if A does a post_process_write(), that affects which texture B will need to read from. How would B know which texture to bind? Maybe I'm missing something about this. |
@IceSentry agreed, I couldn't think of a good name either. @JMS55 Within the node I have a TextureViewId which I swap before the draw functions are called such that the correct bind group is bound. |
I see what you mean. I agree it fits your use case, but it's a very niche situation. I'll approve the PR, but I'd like the docs to indicate that it's probably not what you want 99% of the time. Name is fine imo, I can't think of anything better either. |
Signed-off-by: Torstein Grindvik <torstein.grindvik@nordicsemi.no>
@JMS55 I made the language in the docs even stronger to indicate that this method is only needed when you know you need it.
Yes I think so too. |
bors r+ |
# Objective ## Use Case A render node which calls `post_process_write()` on a `ViewTarget` multiple times during a single run of the node means both main textures of this view target is accessed. If the source texture (which alternate between main textures **a** and **b**) is accessed in a shader during those iterations it means that those textures have to be bound using bind groups. Preparing bind groups for both main textures ahead of time is desired, which means having access to the _other_ main texture is needed. ## Solution Add a method on `ViewTarget` for accessing the other main texture. --- ## Changelog ### Added - `main_texture_other` API on `ViewTarget`
Pull request successfully merged into main. Build succeeded:
|
# Objective ## Use Case A render node which calls `post_process_write()` on a `ViewTarget` multiple times during a single run of the node means both main textures of this view target is accessed. If the source texture (which alternate between main textures **a** and **b**) is accessed in a shader during those iterations it means that those textures have to be bound using bind groups. Preparing bind groups for both main textures ahead of time is desired, which means having access to the _other_ main texture is needed. ## Solution Add a method on `ViewTarget` for accessing the other main texture. --- ## Changelog ### Added - `main_texture_other` API on `ViewTarget`
Objective
Use Case
A render node which calls
post_process_write()
on aViewTarget
multiple times during a single run of the node means both main textures of this view target is accessed.If the source texture (which alternate between main textures a and b) is accessed in a shader during those iterations it means that those textures have to be bound using bind groups.
Preparing bind groups for both main textures ahead of time is desired, which means having access to the other main texture is needed.
Solution
Add a method on
ViewTarget
for accessing the other main texture.Changelog
Added
main_texture_other
API onViewTarget