Contexts cannot be shared across multiple threads on Windows

Issue #22 resolved
Michael Ludwig
repo owner created an issue

At least with Windows 7 (and probably earlier OSs), a context created on one thread cannot be shared with a context on another thread. It would appear that they take locking windows to threads very seriously --> lame.

I will need to think of a suitable solution, although it might just be that windows 7 implementations are limited to a single thread (kind of wastes a lot of the code I wrote...).

Comments (4)

  1. Michael Ludwig reporter

    Online sources have conflicting opinions about this. It might be that context creation only must be done on the same thread but can then be released and moved over to other threads.

    Another option is to have each surface locked to a specific thread, and use separate resource managers if the OS does not allow contexts to be shared.

    How much of this is wanting to keep the complicated ContextManager I figured out a while ago, even though the GPU must have synchronized access.

  2. Michael Ludwig reporter

    A major point to consider is that even if OpenGL drivers support multi-threaded context sharing, etc. the GPU is a single resource that will be a major contention point for access.

    The abstract implementation of renderers, the ContextManager and the ResourceManager will be greatly simplified if I say it only uses a single rendering thread.

    When ready, I should tag the revision that contains the fancy threaded code in the event that drivers improve to make it a valuable option in an engine.

  3. Michael Ludwig reporter
    • changed status to open

    Single worker GPU thread is implemented, all GPU logic including surface creation, etc is moved onto that thread. This solves the issue on Windows using LWJGL. For some reason, JOGL is still having troubles creating contexts but the error message is new.

    Additionally, it appears as though the LWJGL native input polling must be performed on the same thread as that which created the surface or the event queue never gets emptied and windows thinks that it is not responding.

    This means we need to work those poll tasks in between frame jobs, which is unfortunate because I would have liked to keep that completely independent of frame rate. The fix for this is to have a single monitor thread that queues tasks to poll input and check for closed requests.

  4. Log in to comment