Hmm, interesting. Mostly playing around with some odd threading stuff here. I made a system where you have n threads (where n is the hardware concurrency), and the first available thread grabs any tasks that are pushed onto a concurrent fifo task queue and executes them.
Now, originally I had it written so one of those tasks was the final render pass, which does the drawing to an sfml window and the window.display(). The window inputs always happened on the main thread (which was separated from this task system by making it just wait for tasks and then run those tasks, letting other threads "jump into" the main thread for a bit, kinda inefficient but as a stopgap solution it worked).
This worked fine when I was running it with my integrated graphics card (NVIDIA Optimus technology defaulted to this for the unrecognised executable), regardless of how many threads I was using. However,when n was >= 5 (meaning 6 or more threads were in use, one main thread and 5 task threads) it'd render a few frames and then crash.
Modifying the code so both final render and input polling occurred on the main seemed to fix this problem so I'm putting it down under "nvidia opengl multithreading weirdness" and "you dolt, graphics cards are not meant to run on potentially different threads in the same program every render" and moving on.
