On 3. Jun 2009, at 23:18, Jonas Walti wrote: >> - Serialization of the draw calls: Observe the statistics >> > What exaclty do you mean with "Serialisation"? The statistics report > long green boxes and sometimes a bigger red box.
Some kind of de-parallelization of the render threads, either in the driver, OSG or somewhere else. I guess this is the case since you get slower with each pipe added. What is the big red box? Can you find out from the doc, or post a screenshot? The only red box should be for Config::finishFrame, since you're not doing compositing or using a swap barrier. >> - Bad multi-threading driver support: try four nodes on the local >> machine, try 185.x driver >> > W'll try this l8er... The multi-process test is done quickly and will point in the direction of the driver, if it improves performance. >> - Lock contention in osg render traversal: imo unlikely >> > eVolve is slow as well, probably not an osg problem > > Furthermore, the Quadros look a bit bored while rendering. The GPU- > Temp does never hit the 70°C border (btw: does anyone know a good > nvidia GPU measurement tool for linux?). > Ubuntu reports well spread CPU usage (around 50%-60% for all 4 cores > with a simple OSG model but fully 100% with eVolve. This results > into 1-2 FPS with eVolve) This sounds like a driver issue. eVolve shouldn't be CPU-bound, and the GPU's should all be busy. Max - do you have any experience with eVolve on Multi-GPU systems? > Maybe this is because we do not use the SLI tech. Any experience > with SLI/Equalizer out there? SLI is like a driver-based Equalizer (oversimplified). It abstracts multiple GPU's into one. You can use it with Eq, as if you use one GPU. Typically this approach will give you less performance, since you're approaching the problem at a lower level. HTH, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
