Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 2 of 2

Thread: OpenGL and multiple threads

  1. #1
    Junior Member Regular Contributor
    Join Date
    Feb 2004
    Posts
    249

    OpenGL and multiple threads

    Hello, since I haven't been able to find decent documentation on this subject I need to ask these questions here:

    In OpenGL each thread needs its own Rendering Context?

    I can do reads/writes to different DisplayDevices ( ATI extension - make_current_read) but this works only with the same Rendering Context?

    When drawing object A in thead 1 and object B in thread 2, will a readpixels from thread 2 display only object B?

    Has anybody used multithreading with OpenGL succesfully, and what did you gain by it?

    Thanks for any insight into this matter.

  2. #2
    Junior Member Newbie
    Join Date
    Mar 2004
    Posts
    1

    Re: OpenGL and multiple threads

    Originally posted by def:
    In OpenGL each thread needs its own Rendering Context? [...]
    Each thread can have at most one current context. A context can be current for only one thread at a time.
    So, being "current" does not imply that the context must be different. However it implies that one unique context must be exclusively accessed by one thread at a time.
    Recall that OpenGL is by nature a client/server architecture. So having multiple thread issuing commands concurrently in the same context would lead to a breakup of the GL commands protocol and inconsistent status in the state machine.

    Efficient use of multiprogramming, at a safe level, is for example to carry out independent calculations in parallel.
    Obviously multi-threading really pays off on SMP systems.

    If I can remember, when having a decent hardware, GL commands usually are inexpensive to be executed
    (they are buffered by the driver). So generally they should not be considered a major performance hit. What needs the most care in coding is state change (to be minimized), and data transfer.

    I suggest that you reconsider your code and eventually revert to single threading, that in the case you presented would seem to be the natural choice.

    Cheers,
    Paolo

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •