On Wed, Oct 31, 2012 at 10:20 AM, Mark Callow <email@example.com> wrote:On 2012/10/31 17:27, Florian Bösch wrote:Where is it written that bufferData and texImage2D do synchronization?The driver maintains a command queue of things tell the GPU to do. Each command may take an infinite amount of time. In order to speed up overall performance the driver lets the client race ahead of the queue, i.e. calls to the driver return before the commands have finished, this is known as asynchronous execution. If you call finish, then the driver blocks on that call until the command queue is empty. There are 3 different parts of memory that are usually involved in the process of shuffling data around that go with commands: 1) client memory 2) driver memory 3) gpu memory. Driver memory is usually quite fixed and by far and large doesn't implement any elaborate caching scheme, after all, you wouldn't want the driver to segfault with a memory overflow, that would be bad.So what happens if the driver receives a request to upload data from client memory to GPU memory? The driver reads the client memory and puts the bytes onto the GPU. It needs to block while it does that because it needs to be sure to have read all the clients bytes before the client would continue and do things like delete that memory area or change it, resulting in invalid or garbled data. So, how can the driver, with a queue full of things, that are not known to execute in finite time, know when the GPU has gotten all the bytes that the client requested to be uploaded? The answer is quite simple. Since the command to upload was the last command to be put in the queue, the driver knows that the GPU has done all the receiving of client bytes when the command queue is empty. Incidentially, that's the same as flush.So there.