问题
I have a framebuffer with two textures t0 and t1 attached.
On the first pass I render to both of them with multiple fragment shader output.
Before the second pass I do thew following:
- Turn on a shader with one output only
- Bind
t1to a texture unit - call glDrawBuffers to disable writing to
t1's attachment
Note that t1 is used for sampling, but it's still bound to current framebuffer. As I understand, there are no loopbacks in such configuration.
Is it legal in both OpenGL and WebGL?
I made an example which works perfectly in Chrome and Firefox under Linux, but renders a black screen in both browsers for Windows. Is the reason in D3D-backed Webgl implementation, and it's aggressive texture unbinding as pointed here?
回答1:
As I understand, there are no loopbacks in such configuration.
But there is one.
In pre-GL 4.5 (which includes WebGL), feedback loops happen any time you read from a texture which is currently attached to the framebuffer. It doesn't matter if you don't write to it at the moment. It doesn't matter that you can't write to it at the moment. As long as it is attached to the framebuffer, you get undefined behavior from reads to it (unless they are reads from mipmap levels that aren't attached).
In post-GL 4.5 (which doesn't include WebGL) or with the texture barrier extension, this is relaxed. But not enough to solve your problem. UB is still triggered when you try to read from pixels written in a previous call from an image that is still attached to the framebuffer.
So you have to either change FBOs so that the image is no longer attached, or you have to issue a texture barrier (if you have access to 4.5/ARB/NV_texture_barrier, which on desktop GL you probably do).
回答2:
This is illegal in both WebGL1 and WebGL2. WebGL is required to generate an INVALID_OPERATION error if there is a feedback loop.
From the spec section 6.25
6.25 Feedback Loops Between Textures and the Framebuffer
In the OpenGL ES 2.0 API, it's possible to make calls that both write to and read from the same texture, creating a feedback loop. It specifies that where these feedback loops exist, undefined behavior results.
In the WebGL API, such operations that would cause such feedback loops (by the definitions in the OpenGL ES 2.0 spec) will instead generate an INVALID_OPERATION error.
As you pointed out there it sounds like there is probably no actual feedback loop in your case but as Nicol points out according to the spec there still is. This appears to be a bug both Chrome and Firefox.
来源：https://stackoverflow.com/questions/50014874/opengl-and-webgl-sampling-from-a-texture-attached-to-current-framebuffer