I don’t quite understand what you meant by “not productive”.[/QUOTE]
By that I mean everything I’ve read states, with a single GPU, there’s little to no benefit from trying to access that GPU via OpenGL simultaneously in multiple threads. To access GL simultaneously in multiple threads, each needs its own GL context, and GL context switches are expensive. Also, AFAIK there is not a defined subset of the OpenGL API that is guaranteed CPU-only with no per-GPU state locks and thus guaranteed to CPU thread very efficiency against another thread that’s also making OpenGL calls to a GL context bound to the same GPU at the same time.
For instance, check out the Equalizer Parallel OpenGL FAQ.
The only exception I’ve seen to this is that some folks get great results from mapping GL buffers (glMapBuffer) in the GL thread, passing the mapped CPU memory pointers to a background thread, and doing the fill (e.g. memcpy) of that mapped buffer in the background thread. This saves time in the GL thread where it’d otherwise be blocked waiting on that memory fill to complete (which can take several ms for a couple MB of data) and can therefore push more GL commands down the pipe during this time. When complete, a message is sent back to the GL thread to unmap the buffer. Note that this background thread doesn’t need a GL context, and this is perfectly valid as the background thread makes no OpenGL API calls. It’s just shuffling data into CPU memory blocks.
But in the same breath, I’ll caveat that this is all second-hand info. I personally haven’t tried to doing multithread fighting over a single GPU. So please do report back with your results – many will be interested – but read that FAQ above carefully to save you being stumped when if you try something you just get a crash out of it.