I know we can't bind the same texture as an input resource to a shader and as a render target within a single draw call, Direct3D just forces unbinding of such a texture SRV, OpenGL says it's undefined behaviour, and I am not sure about Vulkan.

We can bypass that via Unordered Access Views in Direct3D or Images in OpenGL though.

But the question is: what is the reason of these limitations in case we know that every fragment shader thread reads and writes the same texel just once from hardware perspective?

I can imagine that this won't work due to reads and writes caching if we deal with another case not mentioned above, with some random read/write positions and counts, but what about this specific case I asked about? Shouldn't we safely read values from read cache and write values into write cache and just flush write cache in the end overwriting previous content and do not worry about asynchronous glitches?

  • $\begingroup$ "We can bypass that via Unordered Access Views in Direct3D or Images in OpenGL though." No, you can't. You can't read a texture as an image that you're also writing to as a framebuffer attached image. $\endgroup$ Sep 22, 2021 at 2:58
  • $\begingroup$ @NicolBolas I ment we can use Images to read/write at the same time not using Framebuffer at all $\endgroup$ Sep 22, 2021 at 3:28
  • $\begingroup$ You should read about how feedback loops work in OpenGL. $\endgroup$ Sep 22, 2021 at 13:57


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.