LWJGL Forum

Please login or register.

Login with username, password and session length

Author Topic: VBO and Multithreading  (Read 140 times)

bene_2808

  • Newbie
  • *
  • Offline Offline
  • Posts: 11
VBO and Multithreading
« on: September 28, 2017, 15:55:23 »

Hi,

I know there are plenty of topics relating to this, but no one exactly matches what I actually want to know.
Typical setup: One thread rendering from a VBO, another updating it.

Now what I don't know for example:
Is the VBO locked automatically so only one thread can use it at one time?
And if it is not synchronized: manually always blocking the whole VBO makes no sense to me. Because it is quite big but there's always only a tiny piece of it being modified by the update thread. Is there an automatic way to block parts of a VBO? Or do I have to split the big one into several smaller VBOs and block them by myself, when necessary?

Thanks for every answer! ;D
Logged

Cornix

  • Nerdus Imperius
  • *****
  • Offline Offline
  • Posts: 471
Re: VBO and Multithreading
« Reply #1 on: September 28, 2017, 17:44:42 »

You have to send the VBO to the GPU to render it. When you modify it you need to resend it (or parts of it with glBufferSubData). Any other form of synchronisation is not needed. Just remember that only one thread can have control over the OpenGL context at a time though. Only that thread is able to issue OpenGL commands.

What you can do is have one thread write to a float[] and have another thread send that float[] to the GPU to fill the VBO. You would need to synchronize access to that float[] yourself or else you could get undefined behaviour. Before you do any of that though you should ask yourself if multi-threading is really a good idea for your application. Usually its not.
Logged

bene_2808

  • Newbie
  • *
  • Offline Offline
  • Posts: 11
Re: VBO and Multithreading
« Reply #2 on: September 28, 2017, 19:18:33 »

Ok thx for the reply! :)

You talked about one context I guess. And when talking about two contexts, is THERE automatic synchronization...?

Yeah, that'd be possible and due to lack of a better alternative I'm currently working on a similar approach. The only problem is that in my case it's much more coding and costs a lot of temporary RAM... And yes, I asked myself if multithreading is the right way before even starting over with it, and yes it is  ;D ;)
Logged