Multiple thread support

hi everybody,

i am now writing a multi threaded opengl application but i am unable to generate or bind a texture other than the main thread… how can i do this or add multithread support to openGl…

thanks…

first you must call wglMakeCurrent with HDC and HGLRC which belong to current thread. But Why do you use multitheating aplication, you can have more than one window without multithreating ? :confused:

i am writing a terrain application and want to load data and texture from a different thread while i fly over the terrain… i could load data but unable to generate and bind texture from this second thread…

As I said call wglMakeCurrent before OpenGL functions block or send me your source and I make it for you. xmatt@szm.sk

Originally posted by melkisetog:
i am writing a terrain application and want to load data and texture from a different thread while i fly over the terrain…
Just don’t.
This is not going to gain you anything at all. It will only complicate your code and, if anything happens to performance at all, it will be slower than a single threaded renderer.

Off course it can gain you a lot.
We are having a huge terrain viewer (3D map) as well. In second thread I load data, blend several layers and upload textures to the GPU. Maps are huge (10-20 GB), so without precaching in the other thread there would be a lot of waiting.

I create a dummy, hidden window for the other thread and that thread initializes it’s RC on that window’s DC and uses it from now on. With shared lists, threads can comunicate and share textures, etc. It’s important not to have RC/DC problems when you do multithreading, I guess that can be a wrong part.

Originally posted by Aleksandar Momcilovic:
Off course it can gain you a lot.
We are having a huge terrain viewer (3D map) as well. In second thread I load data, blend several layers and upload textures to the GPU. Maps are huge (10-20 GB), so without precaching in the other thread there would be a lot of waiting.

Is that so?
You do realize that whenever your “prefetch” thread uploads a texture it blocks the GL context for the “render” thread and vice versa?

That is not to say that prefetching per se is a bad idea, it can of course gain you some performance. I’m just saying that doing multithreaded OpenGL for this kind of thing is a misuse of GL’s MT support.

You cannot access a GL context, or shared objects for that matter, simultaneously from two threads. The driver will have to serialize your commands, and that will slow it down.

You may have a point if you do nontrivial preprocessing on the data before upload. But I strongly disagree that you need two threads with access to OpenGL for that. As an alternative design, you could let your prefetch thread load and preprocess the data (and never touch OpenGL) and have the render thread upload it.

In my case, just a portion of work in the uploading thread is done in OpenGL itself. Most of the time is waiting for the disk drive to provide the data and there is some processing of that data too. That would unnecessary stall the main thread - sometimes up to half a minute or more.
Main thread renders the scene with what it has - there is always a minimal cover data set, LOD implemented. In this way, user can interact with the scene with the already uploaded data while all the necessary textures are prepared, or can change his viewpoint which may need completely different data set…

I am maybe misusing GL MT support, but I’m not quite sure how it’s supposed to be used… If two non-overlaping windows which does not share lists are rendered in two separate threads would that hurt OpenGL performance?

I am maybe misusing GL MT support, but I’m not quite sure how it’s supposed to be used… If two non-overlaping windows which does not share lists are rendered in two separate threads would that hurt OpenGL performance?

There’s no such thing as GL MT support. You can always run multiple 3D apps (or games) at the same time, but the performance will suffer on consumer cards. On some professional cards (3D labs), you can run 20 windows and performance will stay rock solid.

If you are targeting consumer cards, then use one GL thread, and 1 thread to load data from disks.
You don’t need a GL context in second thread.
You can load a bunch of texture or models to RAM, then tell the GL thread to upload, then switch back…

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.