> >> * Processor affinity support allowing application to lock > >>cull-draw and database processes to specific processors, thereby > >>avoiding cache coherency problems associated with processes moving > >>from processor to processor. > > > >Does OpenSG need this ? > > This becomes very critical one multi-cpu machines to maintain high > performance. The problem is not only cache coherency, but on NUMA > machines it becomes and issue of memory locality as well. > > For the cache coherency problem imaging you are just rendering a > scene on a multi-core processor. During the first frame the process > is running on core 0, but then what happens if the next time it > renders it uses core 1. All of the cached data on the processor now > has to be flushed out of core 0 and loaded into core 1. It gets much > worse when you consider that the OS could make the thread switch > cores (potentially multiple times) during a single traversal. In > that case the cache is constantly flushing and switching. > > With NUMA the issue becomes even worse because the access time to > main memory can be dramatically different from one CPU to the other > and on some systems (Altix) the data allocated stays next to the CPU > where it was first malloc'ed no matter what CPU ends up needing to > access it. > > OpenSG also has some multi-core cache issues related to the memory > layout of the fc's, but that will hopefully be addressed in OpenSG > 2.0.
I understand. > >> * A Texture Atlas builder has been added to the database > >> optimization classes, allowing either manual or automated > >>setting up of texture atlas. Using texture atlas can improve > >>performance by reducing the number of state changes required to > >>render a scene, and by allowing databases to batched in large > >> groups of geometry, in a form that better suits modern graphics > >>architectures. * > > > >This sounds really interesting but how does one deal with the lowest > >mipmap levels where multiple images are merged into few pixels ? > > I don't know. I think I remember reading something about this in a > Game Gems or a paper somewhere. I think it is used pretty heavily in > games so I am sure there is a solution. >In GL you can impose limits on max/min mipmaplevels, I think. This would be useful. I remember vague reading a paper in combination with a shader so I thought this would only work in combination with a shader. If you can limit it with some simple gl calls this would be very useful indeed. > >>GPU timing stats have been added to the viewer > >>class, provided the time taken to process allow drawing operations > >>down on the GPU for the previous frame. Coupled with the existing > >>timing of CPU update, cull and draw dispatch the stats reporting > >> now provides the end user with a clearer idea of whether their > >> application is CPU or GPU limited and server as a better guide to > >> performance optimization work > > > >ok. > > > >>Is anyone interested in porting any of that over to OpenSG? I know > >> I would be interested in have the Texture Atlas, GPU timing > >>information, and processor affinity. Is there anything we can > >> learn from their COLLADA loader and writer? > >> > >> > >> > >> > >> > >>It also sounds like they have > >>multi-processor rendering which we have coming in OpenSG 2.0, but > >> is there any way to get that into 1.8? > > > >Can you please explain how this works ? Having multiple draw threads > >that call display lists ? Barriers/Mutices needed ? What gain is to > > be expected ? Without knowing details I guess the speedup will be > > low and only noticeable for draw trees with lots of geometry nodes. > > Or could you compile several glsl shaders at the same time (guess > > this happens on the cpu part of the OpenGL driver) ? > > I haven't used it lately, but OSG has always been able to have > multiple draw traversals in parallel. They use a context specific > traversal helper that stores all the details of display lists and > other context specific data. So they achieve linear speedup with > parallelizing calls to draw. But now it looks like they also have > the ability (finally) to support staged rendering much like Performer > did in the past with CULL running for frame 2 and draw is running for > frame 1. Note: I have not looked into the details of this, so I > could be way off. Are we talking single or multiple windows here ? I was talking about single window and coulnd't believe multithreading could be useful. Regards Matthias ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
