You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pixel history's tex after column is incorrect on Vulkan for multiple primitives touching a single fragment in a single draw call with framebuffers without a stencil
#2894
Closed
w-pearson opened this issue
Apr 3, 2023
· 3 comments
I've been looking into implementing dual source blending in pixel history in Vulkan (#2461), and made some progress on it (I've successfully implemented swapping index 0 and 1). However, I noticed that the "tex after" column had incorrect results in it. After some investigation, I've determined that this is an issue with Vulkan pixel history in general, specifically related to framebuffers that don't have a stencil attachment.
I've come to this conclusion because it does work correctly in the VK_Pixel_History test (for the multisampled test, EID 59, at around 140, 140), and that test has a stencil buffer. Additionally, the Vulkan pixel history implementation uses the original framebuffer for post-modification, but still assumes it has a stencil. The Vulkan specification says (emphasis mine):
If the stencil test is not enabled, as specified by vkCmdSetStencilTestEnable or VkPipelineDepthStencilStateCreateInfo::stencilTestEnable, or if there is no stencil attachment, the coverage mask is unmodified by this operation.
i.e. at least as far as I can tell, all of the fragments pass the test. So for 3 triangles, instead of allowing only a fragment from the first triangle, then a fragment from the second triangle, then a fragment from the third triangle, it draws all three triangles three times. (This can also be seen if blending is enabled, though I don't have a great example of this set up.)
OpenGL is also broken in this case, but I haven't investigated what's going on there and it seems to be broken in a different way.
Steps to reproduce
The easiest way to reproduce is to use the following set of modifications to the renderdoc demos program, which change all of the "simple triangle" demos to instead draw 3 overlapping triangles in a single draw call:
I believe those commits should fix this on GL and Vulkan, at least for your test case provided. Adding more permutations of pixel history tests to make sure it works under different rendering setups is on my (very very long) list of tests to add.
OpenGL seems to still be broken. But it seems to be broken in general, not just in this case, so perhaps there's a separate Intel issue? I'll create a new report for that.
I notice you also added marker regions to GL pixel history (04a0fdb), and marker regions also exist for the Vulkan implementation. I assume this is some kind of debugging feature - is there any documentation on how to use it? (I tried launching renderdoc in renderdoc, which seemed like the obvious if a bit silly approach, but that didn't do anything.)
Yes please open a new issue if there are other issues with GL's pixel history, it's working fine for me. Intel GL is a bit dodgy on windows so there may be something there.
Self-hosted capture is possible by renaming the 'renderdoc' and 'renderdoccmd' projects to 'rdocself' and 'rdocselfcmd' and capturing that way, since then it produces a differently named dll that can be capturing while main renderdoc dll is replaying. You'll get new menu items under tools for starting and ending the capture.
w-pearson
changed the title
Pixel history's tex after column is incorrect on Vulkan for multiple fragments touching a single pixel in a single draw call with framebuffers without a stencil
Pixel history's tex after column is incorrect on Vulkan for multiple primitives touching a single fragment in a single draw call with framebuffers without a stencil
Apr 13, 2023
Description
I've been looking into implementing dual source blending in pixel history in Vulkan (#2461), and made some progress on it (I've successfully implemented swapping index 0 and 1). However, I noticed that the "tex after" column had incorrect results in it. After some investigation, I've determined that this is an issue with Vulkan pixel history in general, specifically related to framebuffers that don't have a stencil attachment.
I've come to this conclusion because it does work correctly in the VK_Pixel_History test (for the multisampled test, EID 59, at around 140, 140), and that test has a stencil buffer. Additionally, the Vulkan pixel history implementation uses the original framebuffer for post-modification, but still assumes it has a stencil. The Vulkan specification says (emphasis mine):
i.e. at least as far as I can tell, all of the fragments pass the test. So for 3 triangles, instead of allowing only a fragment from the first triangle, then a fragment from the second triangle, then a fragment from the third triangle, it draws all three triangles three times. (This can also be seen if blending is enabled, though I don't have a great example of this set up.)
OpenGL is also broken in this case, but I haven't investigated what's going on there and it seems to be broken in a different way.
Steps to reproduce
The easiest way to reproduce is to use the following set of modifications to the renderdoc demos program, which change all of the "simple triangle" demos to instead draw 3 overlapping triangles in a single draw call:
Patch to demos to help with reproducing
The same process can be repeated with GL_Simple_Triangle and D3D11_Simple_Triangle. Here are screenshots of the results:
Vulkan:
OpenGL:
D3D11 (correct):
Environment
The text was updated successfully, but these errors were encountered: