<p>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.</p>
<p>We can bypass that via Unordered Access Views in Direct3D or Images in OpenGL though.</p>
<p>But the question is: what is the reason of these limitations <strong>in case we know that every fragment shader thread reads and writes the same texel just once from hardware perspective?</strong></p>
<p>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?</p>

CC BY-SA 4.0
2021-09-22T02:58:49.877Z
"*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
CC BY-SA 4.0
2021-09-22T03:28:47.640Z
@NicolBolas I ment we can use Images to read/write at the same time not using Framebuffer at all
Emil Kabirov
CC BY-SA 4.0
2021-09-22T13:57:54.703Z
You should read [about how feedback loops work](https://www.khronos.org/opengl/wiki/Memory_Model#Framebuffer_objects) in OpenGL.
Nicol Bolas
<rendering><texture><api><multithreading>
Graphics APIs: read/write the same texture
Emil Kabirov
# Graphics APIs: read/write the same texture

(Asked by: username_0 on 2021-09-21)

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?

**Tags:** rendering, texture, api, multithreading

> **Comments:**
> **username_1**: "*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.  
> **username_0**: @username_1 I ment we can use Images to read/write at the same time not using Framebuffer at all  
> **username_1**: You should read [about how feedback loops work](https://www.khronos.org/opengl/wiki/Memory_Model#Framebuffer_objects) in OpenGL.  

---

## 0 answers

