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

[Robert Osfield]

Hi Kouichi,

On 9 November 2015 at 17:35, Kouichi Yoshizawa <
kouichi.yoshizawa23 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20151110/009c1e2d/attachment-0003.htm>