Results 1 to 5 of 5

Thread: Multithreading and OpenGL

  1. #1
    ClanLib Developer
    Join Date
    May 2007

    Default Multithreading and OpenGL

    I tried to create a new example (Commited to 2.2 and 2.3 SVN : Examples/Display/Thread)

    See image:

    The main thread should draw a rotating texture running at full frame rate (currently set at 60fps)

    The worker thread should create the texture.

    The textures are double buffered, so the texture (A) is read from and texture (B) is written to.

    The texture is written to using a CL_FrameBufferObject via an OpenGL shader.

    The shader renders a simple mandelbrot set.

    That's the theory.

    On Windows the example runs very slowly. It seems that the main thread is waiting for the worker thread to complete.

    I am using the latest ATI graphics driver.

    On Linux, the example runs at 60fps. I did not check the example running flatout (without flip(1), and using flip(0) )

    Before the thread starts, I use:
    CL_GraphicContext worker_gc = gc.create_worker_gc();
    That is passed to the thread

    The thread contains: CL_SharedGCData::add_ref(); .... CL_SharedGCData::release_ref();

    Without the add_ref() the application crashes in CL_SharedGCData

    Is add_ref() required?

    On windows, the application crashes on exit with release_ref(). On linux, it works

    Except once, where it crashed the entire ubuntu desktop (freezing the keyboard/display)

    Can someone have a look please
    Last edited by rombust; 11-01-2010 at 04:06 PM. Reason: using latest ati driver

  2. #2
    ClanLib Developer
    Join Date
    May 2007


    I spoke to somebody at ##opengl (at )

    They suggested that there is no guarantee whether the GLSL shader on the graphics card will run in parallel or serial in this situation.

    (i.e. interleaving or queuing the request)

    Can anyone verify this?

    It that is true (and it make sense). The example will need adjusting to create the texture in the worker thread via a pixel buffer object.

    Also the question about CL_SharedGCData add_ref() still remains.

  3. #3
    Join Date
    Dec 2009


    Thanks rombust, very interesting and useful example.
    I'm not sure I understand OpenGL well enough yet, but I would try the following strategy:

    In the renderer thread, create a PBO; no GC sharing. Then loop as follows: map the PBO and then tell the worker thread to write data to it (by passing the PBO's pointer).
    The worker thread draws into the PBO, then notifies the renderer thread when it has finished.
    When the renderer thread receives the notification, unmaps the PBO, calls glTexImage2D() and then renders the texture on the 3D scene.

    Now evolve this scenario to use two PBOs so that you always have one texture free for rendering at your desired rate in the first thread, while the other is being updated by the worker (and pipeline stalls should be minimized).

    Does it make any sense? Apologies in advance if I talked nonsense :-)


  4. #4
    ClanLib Developer
    Join Date
    May 2007



    In the renderer thread, I created a PBO, but still with GC sharing, to show that you can.

    The main thread runs fast (3332fps in that image).

    There still remains some problems:

    1) It crashes on exit (because of the CL_SharedGCData I think)
    2) clanSWRender target crashes (I have not looked at why)
    3) clanGL1 target crashes (probably pbo's not implemented I guess)

  5. #5
    ClanLib Developer
    Join Date
    May 2007


    The problems have now been fixed

    The ClanLib developers decided to remove create_worker_gc()

    The reasons are:
    1) It makes ClanLib implementation more complex. We currently share data between different OpenGL contexts using CL_SharedGCData and wglShareLists. It will be tricky to get it right when also using multiple threads. That is assuming Windows and Linux graphic card drivers fully support it.

    2) There is no advantage in speed on current graphics cards. At this moment in time, it is unknown if using multiple core GPU's would change this. That is assuming it is supported by OpenGL.

    The example has been updated to reflect this. And it should be much more stable

Similar Threads

  1. Using dlopen() with OpenGL
    By rombust in forum Official ClanLib SDK Forums
    Replies: 6
    Last Post: 11-23-2009, 11:01 AM
  2. OpenGL ES?
    By NovaLaw in forum Official ClanLib SDK Forums
    Replies: 3
    Last Post: 10-19-2009, 07:20 PM
  3. OpenGL 2.0
    By madmark in forum Official ClanLib SDK Forums
    Replies: 5
    Last Post: 06-17-2009, 04:21 PM
    By babyvegas in forum Official ClanLib SDK Forums
    Replies: 1
    Last Post: 07-30-2008, 10:07 AM
  5. DirectX VS OpenGL
    By Akolade in forum RTsoft Tavern
    Replies: 5
    Last Post: 08-20-2002, 10:46 AM



Posting Permissions

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