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
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.
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.
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. 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.
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.