Multithreading and VBO

OpenGL Development
#1

Hi,

I want to do some optimization by using the real potential of VBO : multithreading.
The game life cycle is composed of 3 steps :

  • logic
  • CPU -> GPU data transmission
  • rendering

Those steps are organized in 2 threads :

[tr][td]OpenGL Thread[/td][td][/td][td]Transmission[/td][td]Rendering[/td][td]Transmission[/td][td]Rendering[/td][td]Transmission[/td][td]Rendering[/td][/tr]
[tr][td]Logic Thread[/td][td]Logic[/td][td]—[/td][td]Logic[/td][td]—[/td][td]Logic[/td][td]—[/td][td]Logic[/td][/tr]

So the two thread cycles look like :
Logic thread :


while (!finished)
    {
      waitForFPS();
      logic(time);
      mutex.endOfLogic();
    }

Rendering thread :


while (!finished)
    {
      mutex.waitForLogic();
      transmit();
      mutex.endOfTransmition();
      draw();      
      mutex.endOfDrawing();
    }

I have managed to create the “Mutex” class to synchronized the two thread and it works. But I’m not 100% sure of it and I’m not really happy about it :


/**
 *
 * @author Bonbon-Chan
 */
public class Mutex
{
  private boolean lockLogic = true;
  private Object  logic = new Object();
  private boolean lockRendering = false;
  private Object  rendering = new Object();
  
  public void waitForLogic()
  { 
    while(lockLogic)
    {
      synchronized(rendering)
      {
        try { rendering.wait(18); } catch(Exception ex) {}
      }
    }
  }
  
  public void endOfTransmition()
  {
    synchronized(logic)
    {
      lockLogic = true;
      logic.notify(); 
    }
  }
  
  public void endOfDrawing()
  {
    synchronized(logic)
    {
      lockRendering = false;
      logic.notify(); 
    }
  }
  
  public void endOfLogic()
  {      
    while(lockRendering) // Wait for end of drawing;
    {
      synchronized(logic)
      {
        try { logic.wait(18); } catch(Exception ex) { ex.printStackTrace(); }
      }
    }
          
    synchronized(rendering) // Start Transmission
    {
      lockLogic = false; 
      lockRendering = true;
      rendering.notify();
    }
        
    while(!lockLogic) // Wait for end of transmission
    {
      synchronized(logic)
      {
        try { logic.wait(18); } catch(Exception ex) { ex.printStackTrace(); }
      }
    }
  }
}

What do you think about it ?

#2

You have all kinds of spin loops based on testing boolean variables that arent themselves set in a synchronized section and aren’t even marked volatile. This demands the obvious question: how much experience do you have in threads? If you’re not already highly experienced in the topic, you should be using java.util.concurrent instead.

What specifically do you aim to get out of this design?

#3

Yes, I don’t have mush experience in this field. And I had the feeling that is was badly done. I think I have found what I need in java.util.concurrent. Thanks ;D

To work ;). Since I have not a clear idea on what I do, I don’t really know what I should be carefull to (I didn’t think about the volatile for example…).

Well since there is already tools to do thread synchronization, there is a new version that is far better (I hope to) :


/**
 *
 * @author Bonbon-Chan
 */
public class Mutex
{
  private final Semaphore semaphoreLogic = new Semaphore(1);
  private final Semaphore semaphoreRendering = new Semaphore(1);
  private final CyclicBarrier barrier = new CyclicBarrier(2);

  public Mutex()
  {
    try
    {
      semaphoreLogic.acquire();
      semaphoreRendering.acquire();
    }
    catch(Exception ex) { ex.printStackTrace(); }
  }

  public void waitForLogic()
  {
    try
    {
      semaphoreLogic.acquire();
    }
    catch(Exception ex) {}
  }
  
  public void endOfTransmition()
  {
    semaphoreRendering.release();
  }
  
  public void endOfDrawing()
  {
    try
    {
      barrier.await();
    }
    catch(Exception ex) { ex.printStackTrace(); }
  }
  
  public void endOfLogic()
  {
    try
    {
      barrier.await(); // Wait for end of drawing;
    }
    catch(Exception ex) { ex.printStackTrace(); }
    barrier.reset();

    semaphoreLogic.release(); // Start Transmission

    try
    {
      semaphoreRendering.acquire(); // Wait for end of transmission
    }
    catch(Exception ex) { ex.printStackTrace(); }
  }
}

It works and it should be more safe that what I have done.

#4

Two semaphores and a CyclicBarrier is still pretty complex … what I was aiming at was to get you to explain the workings of the system in english, because it’s actually kind of hard to intuit from the code. As far as I can tell, you want rendering to block until the game logic has a frame ready, and you want the game logic to run on a separate core. Is that about right?

#5

I’ve found that it is a little easier to do the rendering in the main thread and “thread out” the logic. That way you’ll have a little less trouble with the GL context during startup.

#6

Logic and drawing are done at the same time.
When Logic and drawing are finished, CPU->GPU data transferts start.
Then logic and drawing wait that transferts are finished to start again.

It is what I am doing.

Edit :

Sproingie, you are right there was a semaphore that was useless :


/**
 *
 * @author Bonbon-Chan
 */
public class Mutex
{
  private final Semaphore semaphoreRendering = new Semaphore(1);
  private final CyclicBarrier barrier = new CyclicBarrier(2);

  public Mutex()
  {
    try
    {
      semaphoreRendering.acquire();
    }
    catch(Exception ex) { ex.printStackTrace(); }
  }
  
  public void endOfTransmition()
  {
    semaphoreRendering.release();
  }
  
  public void endOfDrawing()
  {
    try
    {
      barrier.await();
    }
    catch(Exception ex) { ex.printStackTrace(); }
  }
  
  public void endOfLogic()
  {
    try
    {
      barrier.await(); // Wait for end of drawing;
    }
    catch(Exception ex) { ex.printStackTrace(); }
    barrier.reset();

    try
    {
      semaphoreRendering.acquire(); // Wait for end of transmission
    }
    catch(Exception ex) { ex.printStackTrace(); }
  }
}

with :


while (!finished)
    {
      waitForFPS();
      logic(time);
      mutex.endOfLogic();
    }



while (!finished)
    {
      mutex.endOfDrawing();
      transmit();
      mutex.endOfTransmition();
      draw();
    }
#7

You can do this all with a single semaphore with two permits. The render and logic threads acquire one permit each, and the transfer acquires two permits. It is possible for the transfer thread to get starved that way though, so a CyclicBarrier might in fact be a superior solution there.

However, this three-thread design of yours doesn’t buy you anything that you don’t get with two threads, since you have your other two threads blocking while the data transfer occurs anyway. Just do your data transfers between renders synchronously in your render thread, which will also relieve you of the problem of handing off your opengl context between the threads.

If the logic thread needs to notify the data transfer that data is available, I recommend actually pushing that data over a Queue. If you really must use shared state (and trust me you don’t need it), then you can synchronize on a single Semaphore with a single permit, using tryAcquire() in the transfer section.

#8

It is really difficult to be clear ;D. I DO use only two threads (yes I don’t see the point to have a 3rd thread).

I will take a look on how a semaphore with several permit works.

#9

I think you’re doing something here with Java that you’re actually supposed to be doing with OpenGL. You shouldn’t be using two threads to do this, as such - you should instead consider “Java” being the thing filling up the data at one end and “OpenGL” sucking the data out of the other end. You should arrange a bunch of VBOs in a circular buffer and fill them up up until OpenGL eventually blocks you when you try and map the next one along - meaning your filling is going faster than the rendering.

The next thing you do is double-buffer (or even triple buffer!) your entire world state. This is where you have one thread doing logic on the current world, and one thread doing rendering on the “backbuffer” world. When the logic thread has finished doing logic for a frame, it flips the buffers - this is the point at which you may be blocked if the rendering thread is still rendering. This is where triple buffering could help you.

Just bear in mind it requires you have a deep copy of the entire game state for each buffer.

Cas :slight_smile:

#10

I don’t really get your point.
I do use “double buffering”. My logic work on a copy of the world (cpu side). And my rendering on another copy of it (gpu side). Well I don’t use flipping but copy it that case (which is not a part that it takes a lot of time in some tests I have done).

Has I understand you, OpenGL call has to be done on the two threads : filling VBO on one and rendering call on the other.
Meaning that one call will not block the other (or I don’t see the point). if so is it true for all video card, and for OpenGL and OpenGL ES ?

#11

Using multiple threads is indeed a good idea in this case. By “filling VBOs”, I suppose you mean filling ByteBuffers with data, and then send them in the rendering thread? Or are you using a shared context and all that stuff? As filling a ByteBuffer is relatively slow, this it is indeed a good idea to multithread this part.

#12

Filling VBOs is not slow - it’s probably the fastest thing you can do in Java. You need to fill the VBOs on the OpenGL rendering thread. Filling blocks when OpenGL can’t handle any more in the call to map a VBO that the GPU is still trying to read from. Filling uses the “backbuffer” world copy (Bonbon, you have it right, and deep copy is probably better than flipping as sooner or later someone’s going to have to copy all that data and doing it all in one go is vastly more efficient).

To my knowledge no OpenGL ES GPUs actually use dedicated VRAM so your performance with VBOs on them is not going to be stellar. In fact for my ES sprite engine I’m currently fiddling with I am simply using two giant vertex arrays (not VBOs) and flip between them each frame, though I’m not doing anything fancy using a second world copy and separate logic thread because half the devices I’ll be looking at have only one core anyway.

Cas :slight_smile:

#13

You can avoid any kind of multi-threading or double-buffering by using VBO “orphaning”. It’s the simplest and most efficient way to stream data to the GPU without any synchronization. More details here, make sure you follow the links to the OpenGL forum and read the posts by Rob Barris. Feel free to try out a simple implementation from the LWJGL test package, class org.lwjgl.test.opengl.sprites.StreamVBO.

#14

I tried the orphaning technique but found it can be a bit unreliable in some implementations. But now I just use a circular ring buffer of VBOs and fill them up one at a time until OpenGL stops me from mapping the next one in turn, which means I’ve overtaken the GPU. My game’s single threaded, and OpenGL does everything via the VBOs asynchronously. Perfect :slight_smile:

Cas :slight_smile:

#15

I did something very similar in order to succeed in drawing a mesh which would occupy more than the maximum size of a VBO. Forcing the reallocation of the VBO very often is a bad idea, it really depends on the implementation of the driver. Personally, I used a few VBOs and more direct NIO buffers. At each rendering call, I looped on the content of these NIO buffers, I copied as much data as possible into the VBOs, I used the content (glDrawArrays), I copied, I used the content, and so on… You can even improve this method by using several sets of buffers in a hierarchy, for example to use the disk as a cache.

#16

False. My Nvidia GTX 460m definitely stores VBOs on the GPU. That is kind of the main point of them.
Proof: My level renderer allocates VBOs for each block/subsection only when they are first seen. A 2048x2048 map only needs about 100MB of VRAM when started (zoomed in), but when I zoom out fully forcing all VBOs to be generated it goes up to 1.5GB. I’m not allocating any textures or anything like that. VRAM usage measured with GPU-Z.

#17

Sorry, I meant to say OpenGL ES not OpenGL there.

Cas :slight_smile: