mirror of
https://github.com/GreemDev/Ryujinx.git
synced 2024-11-28 11:50:50 +01:00
Vulkan: Record modifications after changing the framebuffer (#4775)
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.
This commit is contained in:
parent
cc1a933a2f
commit
7c327fecb3
@ -1015,8 +1015,8 @@ namespace Ryujinx.Graphics.Vulkan
|
|||||||
|
|
||||||
private void SetRenderTargetsInternal(ITexture[] colors, ITexture depthStencil, bool filterWriteMasked)
|
private void SetRenderTargetsInternal(ITexture[] colors, ITexture depthStencil, bool filterWriteMasked)
|
||||||
{
|
{
|
||||||
FramebufferParams?.UpdateModifications();
|
|
||||||
CreateFramebuffer(colors, depthStencil, filterWriteMasked);
|
CreateFramebuffer(colors, depthStencil, filterWriteMasked);
|
||||||
|
FramebufferParams?.UpdateModifications();
|
||||||
CreateRenderPass();
|
CreateRenderPass();
|
||||||
SignalStateChange();
|
SignalStateChange();
|
||||||
SignalAttachmentChange();
|
SignalAttachmentChange();
|
||||||
|
Loading…
Reference in New Issue
Block a user