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

Vulkan: Record modifications for barriers after changing the framebuffer #4775

Merged
merged 1 commit into from May 3, 2023

Conversation

riperiperi
Copy link
Member

@riperiperi riperiperi commented May 2, 2023

Our Vulkan backend inserts image barriers when a texture is sampled after it is rendered. This is done via a "modification flag" which is set when a render target is unbound (presuming that a texture has finished drawing to it).

Imagine the following scenario:

  • Game sets render target to texture A
  • Game renders to texture A
  • (render pass ends)
  • Game binds texture A to a sampler
  • Game sets render target to texture B
  • Renders to texture B using texture A (barrier required)

Because of the previous behaviour, the check to add a barrier for sampling a texture actually happens before it is registered as modified, meaning no barrier was added at all. This isn't always the case, but it was definitely causing issues in Xenoblade 2.

This change adds the modification flag as soon as the texture is bound. A barrier will be inserted the next time the texture is used from that point.

This doesn't fix any more complicated issues where a texture is repeatedly sampled while it is currently being rendered.

Fixes visual glitches at lower resolutions in Xenoblade 2 on NVIDIA RTX 3000 and 4000 series GPUs. May fix other cases. Needs some testing to make sure I didn't make any new bugs crop up elsewhere.

Our Vulkan backend inserts image barriers when a texture is sampled after it is rendered. This is done via a "modification flag" which is set when a render target is unbound (presuming that a texture has finished drawing to it).

Imagine the following scenario:
- Game sets render target to texture A
- Game renders to texture A
- (render pass ends)
- Game binds texture A to a sampler
- Game sets render target to texture B
- Renders to texture B using texture A (barrier required)

Because of the previous behaviour, the check to add a barrier for sampling a texture actually happens before it is registered as modified, meaning no barrier was added at all. This isn't always the case, but it was definitely causing issues in Xenoblade 2.

This doesn't fix any more complicated issues where a texture is repeatedly sampled while it is currently being rendered.

Fixes visual glitches at lower resolutions in Xenoblade 2. May fix other cases.
@riperiperi riperiperi added gpu Related to Ryujinx.Graphics fix Fix something graphics-vendor:nvidia Marks an issue affecting only NVIDIA gpus labels May 2, 2023
@OldManKain
Copy link

OldManKain commented May 2, 2023

Fixes XBDE

Before

ryujinx_capture_2023-05-02_12-40-18

After

ryujinx_capture_2023-05-02_12-38-48


Fixes XB2.

Before

ryujinx_capture_2023-05-02_12-10-32

After

ryujinx_capture_2023-05-02_12-33-50

@Foul-Tarnished

This comment was marked as off-topic.

Copy link
Member

@gdkchan gdkchan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, I was expecting a bigger diff.

@marysaka marysaka merged commit 7c327fe into Ryujinx:master May 3, 2023
6 checks passed
@rabidcopy
Copy link

Seems this PR also fixed a graphical issue with Bayonetta 3 as well.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix Fix something gpu Related to Ryujinx.Graphics graphics-vendor:nvidia Marks an issue affecting only NVIDIA gpus
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants