3

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?

Emil Kabirov
  • 183
  • 5
  • "*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. – Nicol Bolas Sep 22 '21 at 02:58
  • @NicolBolas I ment we can use Images to read/write at the same time not using Framebuffer at all – Emil Kabirov Sep 22 '21 at 03:28
  • You should read [about how feedback loops work](https://www.khronos.org/opengl/wiki/Memory_Model#Framebuffer_objects) in OpenGL. – Nicol Bolas Sep 22 '21 at 13:57

0 Answers0