[osg-users] Questions about shared compile contexts and thread safety

[Kouichi Yoshizawa]

Hello,

I would like to learn the status of shared compile context threads in OpenSceneGraph, as I would like to make use of them for performance reasons. My platform is Linux with Nvidia Quadro GPUs that should have good support for shared contexts for GPU transfers.

In 2010 Robert Osfield seems to suggest that shared compile contexts are indeed supported by OSG, although GPU hardware/driver support might be lacking:


> I implemented them [ie shared compile contexts] under Linux with NVidia drivers and they worked as expected, but with other drivers and other OS's reports back from the community haven't been so positive, so it looks like it's a feature that driver developers don't put much effort in to make sure it's solid.


However, in 2014 he seems to be discouraging their use, maybe due to thread safety issues in OSG, or am I reading this wrong?


> The OSG's is written to handling multi-theading of shared contexts as
> handling this special case would require us to add lots of mutex locks
> to all OpenGL code that is setting or using OpenGL objects.
>
> It's better to avoid shared contexts.
>


Inspecting the source code, of particular concern to me is the creation/deletion of GL objects. It appears that the GL object orphan list is accessed without mutual exclusion, from the flush functions as well as the orphan reuse functions during object creation. Therefore these two operations must then never be performed in different threads, but if they are only called from the same thread (the compile context thread in my case) is thread safety then guaranteed? I would be very grateful for clarifications regarding this.

Thank you!

Cheers,
Kouichi[/quote]

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65576#65576





_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Robert Osfield]

Hi Kouichi,

In general I would discourage use of compile contexts except for very narrow usage models.  The main issue comes down to shadred contexts having the potential for conflicts when reading/writing to shared GL objects.  The OSG doesn't have mutexes built into access of GL objects so can only do shared context/compile context if no GL objects will be accessed by the two contexts concurrently.  Adding such mutexes would add a huge burden on all OSG applications.

Robert.

[Kouichi Yoshizawa]

robertosfield wrote:
> In general I would discourage use of compile contexts except for very narrow usage models.  The main issue comes down to shadred contexts having the potential for conflicts when reading/writing to shared GL objects.  The OSG doesn't have mutexes built into access of GL objects so can only do shared context/compile context if no GL objects will be accessed by the two contexts concurrently.  Adding such mutexes would add a huge burden on all OSG applications.

Robert, thanks for the very quick reply!
I want to use the compile context thread only for creating and compiling new geometry and textures while the draw thread is rendering the old objects. Is it then possibe to avoid conflicts with the GL objects? I have already identified that flushing deleted GL objects must in that case be done in the compile thread as well, but are there other such issues to be aware of? Is the IncrementalCompileOperation safe to use as-is with a shared compile context?

Thanks,
Kouchi

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=65580#65580

[Robert Osfield]

Hi Kouichi,

On 8 November 2015 at 17:55, Kouichi Yoshizawa <kouichi.y...@gmail.com> wrote:

Robert, thanks for the very quick reply!
I want to use the compile context thread only for creating and compiling new geometry and textures while the draw thread is rendering the old objects. Is it then possibe to avoid conflicts with the GL objects? I have already identified that flushing deleted GL objects must in that case be done in the compile thread as well, but are there other such issues to be aware of? Is the IncrementalCompileOperation safe to use as-is with a shared compile context?

Personally I'd keep things simply.  Reading/create/optimize the actual scene graph data in a background thread and then use the IncrementalCompileOperation to download objects from the new scene graph bit by bit so your application doesn't break frame.

Potentially you could try compile context but having experimented with it in the past it can work with some platforms and not others, I wouldn’t recommend it.

As a general rule, implement the actual functionality you need in a simple and straight forward way and if it performs how you need it your job is down, use the free time to go for a walk, spend time with family and friends etc. If performance isn't sufficient benchmark it, find out where the bottlenecks are, and only then if you really need to start looking for more complex solutions that might solve your problems.

Robert

 

 

[Kouichi Yoshizawa]

robertosfield wrote:
> Personally I'd keep things simply.  Reading/create/optimize the actual scene graph data in a background thread and then use the IncrementalCompileOperation to download objects from the new scene graph bit by bit so your application doesn't break frame.
>
>
> Potentially you could try compile context but having experimented with it in the past it can work with some platforms and not others, I wouldn’t recommend it.
>
>
> As a general rule, implement the actual functionality you need in a simple and straight forward way and if it performs how you need it your job is down, use the free time to go for a walk, spend time with family and friends etc. If performance isn't sufficient benchmark it, find out where the bottlenecks are, and only then if you really need to start looking for more complex solutions that might solve your problems.

I see what you mean, but the problem is that I'm already doing the above suggestions and my performance is still far from acceptable so something needs to be done. Using a separate thread for GPU transfers will enable what Nvidia calls a "copy engine" that can transfer data in parallel with the rendering, something otherwise not possible. This could potentially provide a huge benefit for my application since it is heavy on both rendering and GPU transfers, so I will try to experiment with making it work. So far it's looking very promising.

Many thanks,
Kouichi

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=65586#65586

[Robert Osfield]

Hi Kouichi,

On 9 November 2015 at 17:35, Kouichi Yoshizawa <kouichi.y...@gmail.com> wrote:

I see what you mean, but the problem is that I'm already doing the above suggestions and my performance is still far from acceptable so something needs to be done.

Are you 100% confident that you are using the most efficient scene graph you can create?  I'd be very surprised if this was the case.

However, as you have only ever talked about the chosen solution for the performance problem, and nothing about the actual nature of the scene graph, OS and hardware you are working with there is nothing others can do to help advice on how you might improve things.
 

Using a separate thread for GPU transfers will enable what Nvidia calls a "copy engine" that can transfer data in parallel with the rendering, something otherwise not possible. This could potentially provide a huge benefit for my application since it is heavy on both rendering and GPU transfers, so I will try to experiment with making it work. So far it's looking very promising.

Using a separate CPU thread and associated graphics context for uploading data to the GPU won't actually directly do this, it'll just provide data to the driver from two threads.  The driver will still be doing what it does to manage all these resources and uploading when it can.   If the bottleneck is CPU pre-processing of the data then you "might" see an improvement.  However, you might well see worse performance with the driver and hardware being more contended.

Using GL buffer objects for data transfer helps the driver in this process and the OSG supports this, the driver can actual start doing async copies where supported even if you are dispatching the GL data/commands from your application single threaded.

Another massive factor in performance when you are pushing a lot of data at the GPU is overall management of GPU memory.  The OS/dirver can really start managing things really badly when GPU memory starts getting full.  Performance can suddenly drop massive, with big stalls when you start getting near the limits.  Using techniques that minimize memory usage and well as memory transfer can be crucial to success.  In OSG-3.4 I introduced displacement mapping based terrain rendering in osgTerrain that shares geometry data between tiiles specifically to address this issue.  While this particular implementation might not be relevant to you the lessons should be applicable.  Modern OpenGL/GLSL opens the door to implementing scenes in different more memory efficient ways, it might involve higher GPU computational loads but by removing a bottleneck you can get far higher and more reliable performance.

So I'd advice you look at scene graph itself for optimizations to get the performance you are after.

Robert.