<div dir="ltr">Hi Kouichi,<br><div class="gmail_extra"><br><div class="gmail_quote">On 9 November 2015 at 17:35, Kouichi Yoshizawa <span dir="ltr"><<a href="mailto:kouichi.yoshizawa23@gmail.com" target="_blank">kouichi.yoshizawa23@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. </blockquote><div><br></div><div>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.<br><br></div><div>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br></blockquote><div><br></div><div>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.<br><br>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.<br><br></div><div>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.<br><br></div><div>So I'd advice you look at scene graph itself for optimizations to get the performance you are after.<br></div><div><br></div><div>Robert.<br></div><div> </div></div></div></div>