Re: glCopyTexSubImage blocks the CPU?

On Tue, 21 Mar 2006 18:09:24 -0700, Michael I Gold <[email protected]>  
wrote:

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

I see, I've thought that the command queue is in software (lock free queue  
in a separate thread) and that the driver converts the commands to hw  
specific opcodes and sends them, when the previous command is finished.  
And that the driver has an efficient way to know about events happening  
inside the GPU via interrupts, or something.. Seems like I was wrong.

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

Well, I guess I'll have to do it myself then. But then it would be nice to  
have a non blocking version of Map(), that would just "peek", and return  
null if not possible to map yet, instead of blocking. Would something like  
this be possible?

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

Thanks for the explanation!



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