what about multi_threading ?

[Nikolai Timofeev]

Streaming -
threads independent contexts ?

[Overmind]

I don't think it's a good idea to make OpenGL threadsafe per default, because it will certainly cost performance for everyone who doesn't want to use it. And the operations would have to be serialized anyway, because the GPU itself is not capable of doing multithreading.

After all, it's not that hard to synchronize access to the GPU yourself. Streaming for example is rather easy: Map the buffer in your rendering thread, write into the mapped buffer in another thread, unmap it in your rendering thread.

[Nikolai Timofeev]

Ok.
Updating textures also with same way -
download data (async. mode) to the pixel buffer object, and than copy (TexSubImage)
it to the target texture. Memory overhead ?

[Overmind]

Of course there is an additional memory overhead if you do it with PBO. The alternative would be to use a synchronous glTex(Sub)Image call in the render thread after you have loaded the texture from file in another thread.

This would trade performance for memory, but you still get the same performance as a hypothetical multithreaded implementation of OpenGL, where the driver has to serialize the operations.

[ZbuffeR]

>> additional memory overhead if you do it with PBO
Why ? Can you elaborate, I am not fluent with the inner workings of PBO, but I though there was less memory overhead ? With glTexImage the driver often keep its own copy in local RAM.

[Overmind]

That's system memory. We have plenty of that.

With PBO, you have to reserve video memory for the PBO plus you need memory for the texture itself. Of course, you can free the PBO when you are finished with uploading the texture, but if it's a dynamic texture you are never finished with uploading