On Thu, Nov 1, 2012 at 3:13 AM, Mark Callow <firstname.lastname@example.org> wrote:Yes but it is not the CPU that would have to block, it is the GPU, waiting for the CPU to finish copying the texture data. The application has no way to tell what the GPU is doing, waiting or busily running a long-winded shader.
Or have the CPU copy the data to the GPU memory while the GPU continues working on the command buffer.
Yeah but any subsequent command could depend on those bytes. So unless you've uploaded the bytes, the next command after the upload can't continue safely. And unless you block you can't fulfill your guarantee that the memory used to pass the bytes is now back in the ownership of the client. And unless you have plenty of free, unused ram and a willingness to nuke the page cache table and blow up the driver memory footprint you can't do a ram->ram copy on write.
I'm not trying to enforce specific sync'ing restrictions. I'm trying to find ways to introduce enough noise that a rogue app. can't reliably determine how long rendering is taking.
The fact of the matter is, you don't know, and can't control, what the driver does and when he syncs. Finish is just one function guaranteed to sync. There is no guarantee any (or all) of the others won't sync. It's up to the driver. OpenGL leaves this entirely unspecified. So trying to shoehorn syncing restrictions into prohibitions onto flush is like trying to plug a hole with a sieve.
NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.