NVIDIA Linux PBO + FBO allows incomplete downloads

Hiya there,

I’m using the 7676 drivers under Linux with a 6800 GT.

I’ve got a couple of strange problems.

Firstly, I’m using a PBO to download images into my FBOs. These are setup to be streaming downloads . OpenGL is allowing these textures to be used before the transfer is complete. I get large, block shaped areas of the texture incomplete. Not very useful.

If I put a GL finish after the download, it seems to solve the problem (although negate it usefulness) but also causes my second problem to appear…

Secondly, I see a problem every 10 frames or so that causes glBindFrameBufferEXT to take 100x-1000x as long as it normally would. It normally takes a few ms and I’ve had it take as long as 4 seconds. All of this time is spent in the GL driver. Anyone got any hints as this is driving me mad.

Jack

Could you post a piece of your code that show what are you trying to do, because im bit confused about your question.

Why you download images into FBO? It is not possible. FBO is replacement for pbuffers and it should be used for rendering to offscreen buffer. Result can be used as texture in following rendering passes or readback to system memory (via PBO or without PBO)

yooyo

If I put a GL finish after the download, it seems to solve the problem (although negate it usefulness)
While it certainly is a bug in the driver that it uses a half-loaded texture (report this bug), when the bug is fixed, the driver will simply be calling glFinish or their equivalent internal function themselves. It has to in order to use the texture.

In order to make async uploading work, you have to have something to do while the texture is being uploaded that doesn’t have anything to do with that texture.

Why you download images into FBO? It is not possible.
It is most certainly possible. Renderbuffers can use glDrawPixels to write to them, and textures can be written to in a number of ways.

And there are reasons for it. Perhaps you’re setting a background image for the render target, one that you’re loading off of disc.

Originally posted by Korval:
[b]While it certainly is a bug in the driver that it uses a half-loaded texture (report this bug), when the bug is fixed, the driver will simply be calling glFinish or their equivalent internal function themselves. It has to in order to use the texture.

In order to make async uploading work, you have to have something to do while the texture is being uploaded that doesn’t have anything to do with that texture.[/b]
I am doing quite a lot of other stuff in between, these are just big textures and take a while to upload. I’ll try and knock together a reproducable test case and submit that, alas it doesn’t help with my current deadline :frowning:

[quote]Why you download images into FBO? It is not possible.
It is most certainly possible. Renderbuffers can use glDrawPixels to write to them, and textures can be written to in a number of ways.
[/QUOTE]Yep, it should behave in this respect just like a normal texture.

Originally posted by Korval:
[b] [quote]If I put a GL finish after the download, it seems to solve the problem (although negate it usefulness)
While it certainly is a bug in the driver that it uses a half-loaded texture (report this bug), when the bug is fixed, the driver will simply be calling glFinish or their equivalent internal function themselves. It has to in order to use the texture.

In order to make async uploading work, you have to have something to do while the texture is being uploaded that doesn’t have anything to do with that texture.[/b][/QUOTE]Careful. The driver need not call glFinish() here. glFinish() is a very heavy hammer that clears the entire OpenGL command stream. When you use PBO to send pixel data, subsequent commands can immediately be applied to the OpenGL command stream asynchronously.

Async uploads are actually easier than async downloads because once you’ve dispatched the data, you just continue on your merry way as if the upload has completed.

As for this issue, it does sound like a driver bug. I’ll check to see if this is a bug that’s known and already been fixed, but if not, a repro case would definitely help.

Thanks -
Cass

Hi jgreasley,

Are you loading the texture data via DrawPixels or via TexImage, and are you “using” the texture thorugh BindTexture or as a render target through FBO? Your initial post is a bit ambiguous as to what “load” means and what “used” means.

Our guess is that the driver may not presently cross-synchronize between FB and TEX usage. But it’s not 100% clear to that your usage does not fall under the “undefined behavior” clause when a given texture is configured for both texturing (BindTexture) and rendering (through FBO) at the same time.

Thanks -
Cass

Hiya there,

I am using a glTexSubImage2D, I need to check but I am pretty sure that it does not fall into the undefined behaviour area.

The workflow is

Create FBO

Use PBO and glTexSubImage2D through Bind Texture

Swap GL context to another thread which may issue some GL calls.

Do some other processing

Regain GL context

(if at this point I use a glFinish, the texture is correct but every 10 frames or so I get upto a 4 second pause. According to the profiler, this time is spent in the GL driver.)

Bind FBO as texture

Render a Quad <-- Texture at this point is missing regular sized rectangles at the right hand side of the texture

I will see if I can knock together a test case showing this behaviour.

Hi jgreasley,

Could you contact me offline about a repro case?
Please email me at cass@nvidia.com.

Thanks -
Cass