Matthias Stiller wrote: >Hello Allen, > > > >> * Support for Windows 64 build >> >> > >OpenSG is already there. > > > >> * Support for IBM's AIX operating system, bringing the total >>number of supported operating systems to 8. >> >> > >Hmm ... well ... whoever needs it. > > > >> * COLLADA plugin support for both the reading and writing of >>COLLADA 1.4 .dae files. >> >> > >nice. > > Yes, this would be very nice to have. I wonder how hard it is to port OSG loaders to OpenSG. Has anyone ever tried it?
>> * 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. > > >> * 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. >>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. -Allen >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
