Re: glCopyTexSubImage blocks the CPU?

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! 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.
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.
Bottom line is: it can be done. And it should be, because procedural  
texture composition will be key in next-gen software (and I'm not talking  
about noise, but art/database guided texture generation), and of course  
caching the results uncompressed is simply out of question with todays  
texture density requirements.

BTW, Evan, when will you guys implement PBO?? My complaint about  
glCopyTexSubImage() blocking when copying into a compressed texture is  
somewhat ridiculous, given that even more basic functionality, like PBOs  
are not yet implemented in current ATi drivers.. :(



Andras

On Tue, 21 Mar 2006 11:34:24 -0700, Evan Hart <[email protected]> wrote:

> Well, the problem would essentially be the second bit there. You are
> copying it into a compressed texture. No hardware that I am aware of
> compresses to the common compression formats directly. It is most likely
> executing a finish, reading the data back, compressing it then
> performing the equivalent of a compressed texsubimage from the host.
>
>   -Evan
>
> -----Original Message-----
> Andras Balogh
> Sent: Thursday, March 16, 2006 1:29 AM
> To: Multiple recipients of list OPENGL-GAMEDEV-L
>
> I'm posting this again (apologies, if you receive it twice), because
> it seems to me my last post did never arrive to this list..:
>
> Running the profiler on my app, it shows a big spike at the
> glCopyTexSubImage call. I admit that my usage scenario is a bit odd:
> I'm copying from an FBO straight into a compressed texture. Still, I
> can't see why it would have to block the CPU.. Is this a driver
> problem? I'm running a GF6600 with 81.98 drivers.
>
> Thanks,
>
>
> Andras
----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Andras Balogh
  INET: [email protected]

Fat City Hosting, San Diego, California -- http://www.fatcity.com
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [email protected] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).