On 13. Jan 2008, at 12:58, Gordon_Erlebacher wrote: > Hi Stefan, > > Thanks for the help. After making the suggested changes, the first > rendered image > happened faster. But rotating the image did not appear significantly > faster. I did > not benchmark though.
It shouldn't make a huge difference whether the first or subsequent frames are assembled. > > The only bottleneck relative to 2-pipe.DB.eqc should be transferring > data to my > mac. The original config runs completely interactively the HPs (at > work). Correct. The transfer happens through the indirectly glDrawPixels executed on the remote machine and displayed on the local machine - hardly the most performant way of doing this. ;) > I did get speedup by reducing the viewport in "Channel3" (my home > mac). That is reasonable. > Is Equalizer simply transfer the bitmap from the assembled version > to my home machine or is > something else going on? See above - the Equalizer does a glDrawPixels. The transfer happens through the indirect rendering. > Suggested Use Case: > > I'd like to wrap en Equalizer code in a Web Service for remote > visualization, or even collaborative > visualization. To this end, the following mode would be useful: the > final bitmap generated by > Equalizer (a simple color buffer) should be sent to some stream (or > a a user-specified socket). For a prototype this hook can be implemented in Channel::frameAssemble. One can access the raw pixel data here - see src/lib/client/compositor.cpp on how to do this. The trick is to find out which of the frameAssemble invocations is the 'final' one to distribute. For a prototype one could use a special output frame name, e.g., 'frame.channel1.export'. > This could be set in the configuration file. Agreed. > That socket can then be use by an external program to > do what it wants (perhaps this will be the case once Chromium is > integrated? I have no direct > experience with Chromium). If you could help me with this, I > "might" be happy to help out. I was thinking of exporting it through the VNC protocol. This would allow integration with VNC proxies. I haven't looked at the VNC code yet to see how this can be implemented. I think it should be some flag on the output frame. I'll think about it a bit - if you have suggestion I am happy to hear them. You can also start gathering all this in a design document, see the existing ones in website/documents/design/. > Another Use Case > > I'd like to construct configuration files on the fly, assuming I am > in an environment where GPUs > are used for computation, and jobs are being submitted by a > scheduler. I would not know in > advance which GPUs in a particular cluster would be used. You can construct configurations programmatically - the configTool does just that. There is currently an undocumented Server::useConfig() method. This might go away in the future, but would be replaced by an API providing the same functionality. HTH, Stefan. _______________________________________________ eq-dev mailing list [email protected] https://in-zueri.ch/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
