PDA

View Full Version : Ping-pong PBO Transfers on a thread



Bruce Wheaton
03-08-2011, 10:39 AM
I'm doing my (video) texture transfers on threads, using PBOs. I know this isn't regarded as optimal, but it works well, and will let me move to VDPAU easily (i.e. I'm not changing that approach).

But I have had a fairly strong PBO > texture linkage that may be unnecessary. I have been using a pool of PBOs, each with linked textures. Is changing the texture a PBO points at a cheaper operation? Or are PBOs lightweight enough that I can keep many around?

The other thing is the dreaded OpenGL cross-thread synchronization issue. I have been using a nice system where I render to an FBO (which I needed to do anyway) and then query (gently) on the end of that drawing. That seemed to let the transfer and render happen without fighting with the main thread.

If I wanted to just tell whether the PBO had finished transferring - but not access it on the secondary thread/s, what can I query on? I need to gently poll whether the transfer is happening, hopefully not blocking the CPU or forcing OpenGL to do work at an inefficient time.

Bruce

Alfonse Reinheart
03-08-2011, 12:05 PM
Buffer objects do not point to textures and vice versa (unless it's a buffer texture, which is a separate type of texture). There is no "linkage" between a buffer object and a texture. When you use buffer objects for pixel transfer, all that happens is that the texture copies its data to/from that buffer object. Once the copy completes, there is no relationship between that buffer and the texture.


If I wanted to just tell whether the PBO had finished transferring - but not access it on the secondary thread/s, what can I query on?

Use a fence (http://www.opengl.org/wiki/Sync_Object).

Bruce Wheaton
03-08-2011, 08:17 PM
OK.... so I had implied more of a link - used the same texture for each PBO. I'm hearing there's no need for that? So I only need as many PBOs as I will have active transfers, not textures in the pool

I do use a fence now, but in an asynchronous transfer, where does that go? The command that starts the transfer returns immediately, therefore a fence right after it will read as true right after the command executes (not the transfer). There have been discussions, as I recall, with tricks to 'touch' a pixel, so there is a command that requires the actual transfer to have taken place - that's what I'm after.

Alfonse Reinheart
03-08-2011, 09:11 PM
The command that starts the transfer returns immediately, therefore a fence right after it will read as true right after the command executes (not the transfer).

That's not how commands work (http://www.opengl.org/wiki/Synchronization). Fences wouldn't be useful if they just told you when control has returned to a thread because, well, you know when control has returned because you're in that thread. They tell you when all prior operations have completed.

Bruce Wheaton
03-08-2011, 09:25 PM
Huh, OK. I guess I had assumed that the command had 'happened' even though the transfer happened, I guess that's true from the CPU's perspective, not the GPU.

Ok, great, thanks. I'll move my fence to right after I start the transfer, and test as before. I've been using NV_fence and Apple_fence on Linux and Mac, respectively. I'd guess there's going to be some 'to flush or not to flush' shenanigans, but there was anyway - I guess it's undefined whether flushed commands in one thread cause commands in another thread to flush.