Re: glCopyTexSubImage blocks the CPU?

Andras Balogh wrote:

> This is what I've been told by others too, but I don't buy it as 
> valid  reasoning. Even if compression is done in software, the driver 
> shouldn't  need to execute a Finish()! This CopyTexSubImage() command 
> (even if it  means download/compress/upload) could be queued the same 
> way every other  OpenGL command is. There's no need for 
> synchronisation between the  execution of this command and my application!

If the operation could be performed by the GPU the driver very possibly 
might queue your command and return.  The fact that it requires software 
assistance means that all pending rendering must be allowed to finish 
before the driver can process the copy, exactly as Evan describes.  Even 
if the driver queued your request, you would still observe a stall 
sometime later when the driver decided to process the queue.  There's no 
getting around this.  At some point the driver needs to wait for the 
hardware to idle before touching the pixels with the CPU.

> I don't need the results of  this command in my app! Also, if I just 
> copy to a non-compressed format,  the driver still has to wait for the 
> data to be rendered into the FBO, yet  it doesn't block my app! 
> Compression (whether it's done in sw or hw)  shouldn't change that.

Your understanding of driver internals is flawed.  hw vs sw is the 
critical factor here.  Without synchronization you will have unreliable 
results due to the race condition.

> If you're not convinced, then just consider this: I could do the same  
> thing manually, by first reading the pixels into a PBO, which is  
> asynchronous operation, then Map() and compress it a couple frames 
> later,  then upload again from PBO, and voila, there's no blocking! Of 
> course,  doing this myself would be a pain in the a$$, and I also 
> don't know when I  can Map() the buffer without blocking, so I'll 
> probably end up waiting  more than necessary.

Yes, its much easier for the application to manage this.  For the driver 
to do this would require a mechanism to track when you wish to render 
with the texture (forcing a validation in case the very next command 
wants to use the texture), notice that there is a pending copy to the 
texture, see if its done, then uncompress the data, copy in the fetched 
pixels and finally allow rendering to continue.

Meanwhile, every application has to endure the overhead of the mechanism 
as well as the additional bugs caused by the complexity and maintenance 
burden of supporting this corner case.

The behavior you desire is a perfectly reasonable idea, and I agree it 
would be nice... but you asked why its slow today, and that's the reason.