Skip to content

Commit

Permalink
Vulkan: Record modifications after changing the framebuffer (#4775)
Browse files Browse the repository at this point in the history
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.
  • Loading branch information
riperiperi committed May 3, 2023
1 parent cc1a933 commit 7c327fe
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion src/Ryujinx.Graphics.Vulkan/PipelineBase.cs
Original file line number Diff line number Diff line change
Expand Up @@ -1015,8 +1015,8 @@ public void SetRenderTargetColorMasks(ReadOnlySpan<uint> componentMask)

private void SetRenderTargetsInternal(ITexture[] colors, ITexture depthStencil, bool filterWriteMasked)
{
FramebufferParams?.UpdateModifications();
CreateFramebuffer(colors, depthStencil, filterWriteMasked);
FramebufferParams?.UpdateModifications();
CreateRenderPass();
SignalStateChange();
SignalAttachmentChange();
Expand Down

0 comments on commit 7c327fe

Please sign in to comment.