GS/Vulkan: Work around NVIDIA attachment clear bug

[stenzek]

Description of Changes

Using vkCmdClearAttachments() within a render pass on NVIDIA seems to cause dependency issues between draws that are testing depth which precede it. The result is flickering where Z tests should be failing.

Breaking/restarting the render pass isn't enough to work around the bug, it needs an explicit pipeline barrier. As far as I can tell, this is a driver bug, because attachment clears should occur in rasterization order, quoting the spec:

Unlike other clear commands, vkCmdClearAttachments is not a transfer command. It performs its operations in rasterization order. For color attachments, the operations are executed as color attachment writes, by the VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT stage. For depth/stencil attachments, the operations are executed as depth writes and stencil writes by the VK_PIPELINE_STAGE_EARLY_FRAGMENT_TESTS_BIT and VK_PIPELINE_STAGE_LATE_FRAGMENT_TESTS_BIT stages.

The 96 index draw has Z testing on, but writes are off, and relies on the buffer having legitimate data. If this was solely an issue with the attachment clear, restarting the render pass would have fixed it... so something more complex is going on here, which I don't think we have visibility into at the application level.

And it's not the first bug we've hit with NVIDIA and attachment clears. Shame, because having the additional render pass sucks.

Rationale behind Changes

Fixes flickering in Lego Batman: The Videogame.
Before:

After:

Suggested Testing Steps

Check Lego Batman dump on NVIDIA, and other vendors, to see if they trigger the bug. The workaround code path is only enabled for NVIDIA.
LEGO_Batman_-_The_Videogame_SLUS-21785_20230712021138.gs.xz.zip

[bigol83]

Nvidia graphic card, dump looks fine.