multithreaded texture loading

Hi folks,

I think this topic has been discussed from time to time, but I’m not sure there have been any clear conclusions :slight_smile:

Anyway, I’m making a multithreaded OpenGL application. The main thread does all the rendering, and a separate thread is used for loading textures and other data from disk.

For the textures, the data reader loads the image data from disk, and the main thread does the actual texture binding and upload, to avoid having to lock the gl context.

Now, what I’m wondering is if there is anything to gain from having a separate GL context in the reader thread and sharing the textures with the main thread GL context. Then I could do the texture uploads from the reader thread too and there would be less work in the main thread. What kind of synchronization would I need to do for this to work? Can I expect this to be well supported across a wide range of platforms and graphics cards? (The application runs on Windows, Linux and OSX).

Any thoughts on this?


From what I’ve read, the “best” way of doing this is to use a pool of PBO’s. Bind and Map an available PBO in the main thread, then hand the mapped pointer over to the loader thread. The thread can then decode into the PBO directly (ok if you write sequentially, bad if you read afaik), or just copy the decoded image into the PBO. It then signals the main thread which Unmaps the buffer and initiates the texture upload.

Depending on how you pass the info to the thread and back, you might not even need any special synchronization.

There was recently a good thread about this, try searching for it.

Nvidia should have good support for this, not sure about ATI though.

Ok, I’ll check that out.

However, after some more analysis, it turns out that uploading textures isn’t the bottleneck here, but compiling shaders is.

I’ll start a separate thread on this topic