SDL vs SMP...

[Ryan C. Gordon]

Svn revision #385 adds the SMP code to sdl_glimp.c...however it does not
work yet. It shouldn't affect non-SMP builds, or even the SMP binary if
r_smp is set to 0.

I put this in the Makefile for the Mac. To add it to Linux, etc, you'll
want to add "sdl_glimp_smp.o" to your platform's Q3POBJ_SMP variable in
the Makefile, and remove "linux_glimp_smp.o" if it exists. There isn't a
matching sdl_glimp_smp.c file, but the Makefile uses this to know to
rebuild sdl_glimp.c with -DSMP on the command line.

The problem is that most platforms do not have thread-safe OpenGL
libraries, including MacOS and (I think!) Linux. The existing Linux code
was just setting the current GL context to NULL in one thread and
resetting it to the previous value in the other thread as it switches
between them, which apparently helps the GL work out threading issues.

SDL, however, wants you to make all video and OpenGL calls from the main
thread, mostly for these sorts of reasons, and does not expose a
MakeContextCurrent() entry point abstraction (partially because it only
allows one GL context at this point), so this is naturally a problem. On
the Mac, this blows up inside the first glViewport() call, and I bet
Linux won't fare much better.

So, if anyone understands the SMP code at all, there are two questions:

1) How hard would it be for the renderer thread to be the intial thread,
and instead spin a thread for the game logic? In other words, we need to
swap the two threads and otherwise function as before if possible.

2) Does the non-renderer thread ever make any GL calls at all? Even
state queries?

Ideally, we make the renderer thread the main thread and never call into
OpenGL from the other thread. This would fix the problem and also speed
up the existing code, since there wouldn't be GL context-switch overhead
every frame.

Is this even possible? Or sane?

--ryan.