Strange error when copying texture to fbo

Hi,

I have a strange problem when copying a texture to a Framebuffer object.
I have a texture T which I want to copy to a Framebuffer object, this fbo is then used later as a texture (but in the same frame). I have to do this, since I cannot use T directly. What I am doing is setting up an empty VAO, set the fbo and render a fullscreen triangle with the texture T set. When I use the fbo as a texture later in the frame, the image is crippled (but one can “see” what it should look like). I dumped both T and the fbo to disk, both look fine. One thing I noticed is when I copy the fbo image to host memory using glGetTextureImage, the fbo is fine when used as a texture then. So it looks like it is something wrong with syncing. I tried glFlush, a fence, some barriers. Nothing worked. What is the proper way to ensure the fbo write has finished before using it as a texture? I thought the driver would take care of this. (I am working with an AMD E9720 GPU here with up-to-date drivers on Windows 10).

thanks for any hints

best regards
pettersson

IMG-20181102-WA0000

[QUOTE=pettersson;1292903]I have a strange problem when copying a texture to a Framebuffer object.
I have a texture T which I want to copy to a Framebuffer object, this fbo is then used later as a texture (but in the same frame).
I have to do this, since I cannot use T directly.[/QUOTE]

Your terminology is confused.

A framebuffer object (FBO) by itself is useless. It’s a container. And it cannot function as a texture.

In order to do anything useful with an FBO you have to attach renderable images to it. The two types of images you can attach to it are textures and renderbuffers. Once suitably setup, then you can use the FBO as a target for rendering.

One thing I noticed is when I copy the fbo image to host memory using glGetTextureImage, the fbo is fine when used as a texture then. So it looks like it is something wrong with syncing. I tried glFlush, a fence, some barriers. Nothing worked. What is the proper way to ensure the fbo write has finished before using it as a texture? I thought the driver would take care of this.

It depends on how you’re doing the writing. Post more about what you’re doing, both in how you’re writing to it and how you are reading from it after that.

Also re synchronization, as a test only, try a glFinish() instead of a glFlush(). That’s the sledgehammer that forces all work to complete before any work issued after that can start.

Hi,

sorry for being unclear. The FBO actually has a texture attached.
So what I do is as follows:

  • get texture T
  • bind FBO
  • bind shader and set texture T
  • draw a fullscreen triangle
  • unbind FBO

now when I use the texture attached to the FBO (as a texture for a different shader later in the frame) I get the aformentioned broken output. If I call glGetTextureImage on this texture (directly after using it as a render target), the data looks ok (I dump it to disk) and displaying the texture on screen is not broken anymore. I will try to use glFinish as soon as I am back at my workplace computer.

[QUOTE=pettersson;1292907]…when I use the texture attached to the FBO (as a texture for a different shader later in the frame) I get the aformentioned broken output.
If I call glGetTextureImage on this texture (directly after using it as a render target), the data looks ok [/QUOTE]

If there’s only one context and one thread involved here, this sounds like a driver bug. Even if you’re doing state tracking to avoid needlessly rebinding the FBO texture to the context, you shouldn’t need to rebind it in this case.

Now if there are multiple contexts involved, where the texture was rendered to on one context and rendered from on another context, then you’d need to bind it (as well as utilize some synchronization to make sure that everything flows properly).

You might post a short, standalone GLUT test program that illustrates your problem so folks can try it and provide feedback.

[QUOTE=Dark Photon;1292910]If there’s only one context and one thread involved here, this sounds like a driver bug. Even if you’re doing state tracking to avoid needlessly rebinding the FBO texture to the context, you shouldn’t need to rebind it in this case.

Now if there are multiple contexts involved, where the texture was rendered to on one context and rendered from on another context, then you’d need to bind it (as well as utilize some synchronization to make sure that everything flows properly).

You might post a short, standalone GLUT test program that illustrates your problem so folks can try it and provide feedback.[/QUOTE]

Hi,

thanks for your comment, it made me recheck the whole application and fix some sync problems :slight_smile:

So what fixed it?

Hi,

sorry for the late response. It looked like I created the texture in the wrong context. I just rewrote most of the code, since I was trying different things, and it became a mess anyway.

Ok, good deal. Glad you got it figured out!