OpenGL and pthread.

Hi,

I am trying to use two threads to render a large array of objects. Each thread will render half the array of objects at the same time. It seems OpenGL would not allow me to do this. I would appreciate very much if anybody give me some help or suggestions?

Here is the scenario:

I have an array of
struct position {
float x, y, z;
};

position a[n];

At rendering:

glBegin(GL_POINTS);

// create both threads and then start them here.

glEnd();

In each thread, I simpley use the following command:

for (int i = start_idx; i<end_idx; i++)
glVertex3f(a[i].x, a[i].y, a[i]z);

where start_idx and end_idx are array index boundaries for each thread.

Originally posted by KevinL:
<…> Each thread will render half the array of objects at the same time.<…>
No. Your graphics card is not a multithreaded device. You’re barking up the wrong tree.

glBegin/glVertex*/glEnd isn’t the best recipe for performance either.

Putting performance aside for a second, I think the real issue here is that you must put glBegin/glEnd into the render threads, too, to make it actually work.

I can deal with performance issue using various techniques. My question here is if OpenGL works when two threads are issuing OpenGL commands at the same time.

I actually just did a quick test putting glBegin/glEnd() in the threads. The same problem occurred, causing program segmentation fault. My feeling is that I just can’t issue OpenGL commands at the same time in different threads. If this is true, I should give up trying.

Any suggestions?

Originally posted by zeckensack:
[b] [quote]Originally posted by KevinL:
<…> Each thread will render half the array of objects at the same time.<…>
No. Your graphics card is not a multithreaded device. You’re barking up the wrong tree.

glBegin/glVertex*/glEnd isn’t the best recipe for performance either.

Putting performance aside for a second, I think the real issue here is that you must put glBegin/glEnd into the render threads, too, to make it actually work.[/b][/QUOTE]

If you really need to use multiple threads, you need to switch context the the current thread every time the current thread wants to issue GL commands. So you can’t really render at the same time without switching thread context all the time (and locking it). And no, you can’t use on glBegin/End pair for multiple threads either.

  • elias

optimal is 1 thread - 1 context (context switching is expensive).
In parallel can be done user input/ mathematics/ sound/etc.

Some drivers use SMP system for rendering(on PC - old 3DLabs Oxygen 2x0/4x0), but current NV/ATI is single threaded.

Only one thread can issue commands to a given OpenGL context at the same time. Even worse; on typical hardware, only one command stream can be read at a time, so even if you have multiple contexts, you’ll end up serializing in the driver.

Trying to draw to the same context from different threads is not expected to perform well; it would force horrible synchronization penalties; and it seems like you could probably come up with a better design that uses the context only from a single thread.

Thanks guys. I think I should stay with one thread for one context based on all the comments from you guys. Cheers!

Originally posted by jwatte:
[b]Only one thread can issue commands to a given OpenGL context at the same time. Even worse; on typical hardware, only one command stream can be read at a time, so even if you have multiple contexts, you’ll end up serializing in the driver.

Trying to draw to the same context from different threads is not expected to perform well; it would force horrible synchronization penalties; and it seems like you could probably come up with a better design that uses the context only from a single thread.[/b]