I’m wondering whether there’s some pitfall in the approach below, where I’d have modules’ Draw() called in the main thread’s loop to serialize OpenGL stuff, whereas Update() for modules are looped in a separate thread and I’m trying to parallelize the skinning of 3D models and putting into buffers that will be loaded to vertex buffer objects (the latter must be serialized since it’s accessing GL):
void Module::Draw(void)
{
… // Other GL stuff
for (int i = 0; i < buffers.size(); ++i)
{
SDL_SemWait(signal0);
Buf *b(atomic_queue.pop());
vbo[i].Load(b->data, b->vCount);
… // Draw VBO here if doing immediate render
}
SDL_SemPost(signal1);
… // Sort and draw VBOs here if doing delayed render
… // Other GL stuff
}
void Module::Update(void)
{
… // Other stuff
SDL_SemWait(signal1);
#pragma omp parallel for schedule(dynamic)
for (int i = 0; i < buffers.size(); ++i)
{
… // Calculate and put vertex data into buffer
atomic_queue.push(&buffers[i]);
SDL_SemPost(signal0);
}
… // Other stuff
}
signal1 is initialized to 1, signal0 to 0; the waits are to prevent either module from going extra frames ahead, while still allowing Draw to start a read on any buffer that has been written by Update’s OpenMP thread pool. atomic_queue would be based on _InterlockedExchange (the intrinsics emitting compare-and-swap instructions). I figure it’d be also easy to extend this to allow Update() to go more frames ahead by using double or triple buffering for the vertex data.