Multiple threads with GL contexts?

OpenGL Development JOGL Development
#1

Firstly, hi everyone.
I’m a final year student at Teeside Uni, and for my practical project I’m producing an in-car computer software package in java, that uses JOGL for rendering.

I’ve hit a bit of a performance hurdle and was wondering if anyone could help me out;

Basically, when the system goes into ‘driving’ mode it starts up a load of threads; one for each piece of telemetry (speedometer, tachometer, lights & gauges etc).
Each of these threads has a JWindow that it attaches a GL Canvas to, loads a couple of textures and starts rendering using an animator (they will eventually get their data across a network).

The problem I’m having is that if I try to start any more than about 5 of these threads simultaneously my system goes very slow for about 30 seconds before the JWindows appear fully and start rendering smoothly (this is on a Core 2 Quad + GE Force 8800 GT).

I’d intended to have one of these threads for every gauge & light that cars of varying spec could show for the sake of concurrency (part of the scope of the degree project), and suggest that it could run on a small integrated computer with a JVM & hardware accelerated graphics!

Is there any way to make this happen faster, avoiding the need to do all rendering in a single thread?

#2

The simple answer is - no. Do your rendering in a single thread. Get your telemetry threads to read in stuff asynchronously, and feed the results into a message queue in your rendering thread. Each frame you render you can read the telemetry data out of the queue and update your rendering model before drawing the display. This is far and away the fastest easiest bestest way to do it.

Cas :slight_smile:

#3

Thanks,

My networking component, which I’ve basically built on top of UDP, uses integer and float objects that have synchronised get() and set() functions. Senders and listeners run in their own thread, constantly sending or recieving UDP packets, and share the same objects with the rendering thread.

Would a message queue be more suitable for the render loop than simply getting the values from the network objects during rendering?

With it being a real-time application with driver safety considerations, it is completely time critical; the slightest stutter in performance is unacceptable, as are extended loading times.

#4

As long as the synchronized get()/set() functions do not block, you are fine with polling from the networking object. But keep in mind that in a simulation environment you might want to consider all packets (polling might loose some values), so a message queue with timestamp might give more accurate results.

#5

Yeah I covered that, basically with it being time critical it doesn’t matter if some packets get lost; as it’s more important that they arrive on time.

That’s why theoretically simulataneous rendering of each gauge was intended; so the data is very up to date; though saying that rendering gauges as a few quads is probably quicker than the network itself.

#6

As long as rendering and eye perception is involved, multiple threads only hurt. You can poll and render helluva lot of data in a frame with opengl.

Actually “hard realtime” applicatons do not try to do everything as fast as possible, but instead guarantee constant (small) response times. I doubt, that much multithreading is involved there…