On 5. Jan 2009, at 11:08, Mathias Heyer wrote: > First I tried a SFR-style config with a classic 2D load balancer. It > worked almost right out of the box. It didn’t give a performance > boost, though. But I think, this is more a driver issue than > Equalizer’s fault. The the additionally required glReadPixels()/ > glDrawPixels() calls might also prevent optimal performance. What is > your experience here?
It depends on your base frame rate and data structure. As a rule of thumb, you don't get much speedup after ~20FPS. The pixel transfer is the major bottleneck on the Equalizer side. There are a couple of optimizations left to be implemented - namely PBO transfers and async readbacks. For PBO there is experimental code (see eqPixelBench), but so far I couldn't get it consistently to work faster than normal readbacks. View frustum culling, fragment complexity and your data structures are an important factor as well. > But again, I could not gain any performance increase. Is that even > possible with Equalizer (in the context of this config and hardware > setup) ? For AFR to work, the render-start of both pipes _must not_ > be locked to each other, but instead, they should be offset by ca. > half a frame. > > So my question is: How to make DPlex work (optimally) on MGPU- > Machines? You need one pipe (thread) for each channel (see 5-window.DPlex.eqc). If your thread model is draw_sync (the default) you'll need one node (process) per GPU, otherwise your draws are serialized. The statistics should show nice overlapping green draw operations between the two GPU's. HTH, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
