Hi DRC, Since I cant comment on a closed bug, I'll do it here:
Begin forwarded message: > Initial Comment: > Not sure if it's a bug, but: > > I have an application using multiple GPUs. There are nGPU + 1 display > connections. The nGPU ones use :0.n, and the +1 uses the ssh X11 forwarding > (node:10.0). Basically the n GPUs render offscreen, and the +1 receives the > pixels from these GPUs for display. > > In such a configuration vglrun selects the proxy compression, I guess because > it sees the local display connections. I have to manually use 'vglrun -v -q > 100 -c jpeg ./release/bin/eqPly' to use jpeg compression for the visible > window on node:10.0. > >> Comment By: D. R. Commander (dcommander) > Date: 2011-12-22 14:28 > > Message: > From the documentation: > > http://virtualgl.svn.sourceforge.net/viewvc/virtualgl/vgl/trunk/doc/index.html#VGL_COMPRESS > > "If the DISPLAY environment variable begins with : or unix:, then VirtualGL > assumes that the X display connection is local. If it detects that the 2D X > server is a Sun Ray X Server instance, then it will default to using xv > compression. Otherwise, it will default to proxy compression. If VirtualGL > detects that the 2D X server is remote, then it will default to using yuv > compression if that X server is a Sun Ray X Server instance or jpeg > compression otherwise." > > However, this assumes that the app is always making a connection to the > same display. If it's making a connection to multiple displays, then > VirtualGL will choose an image transport based on the first display that is > made active in OpenGL (via a call to glXMake[Context]Current().) If that's > one of your sub-renderers, which are using local displays, then VGL will > choose the X11 transport as a default. Thus, if you want the default > behavior to be triggered off of the main renderer and not the > sub-renderers, you would need to initialize the main renderer first. > > Closing, since my understanding of the issue is that it's intended behavior > in VirtualGL, but please feel free to add comments if you have further > insight or if my understanding is incorrect. Agreed: A useful, if feasible, extension to this heuristics would be to postpone the decision to the first glXMakeCurrent of a context to a visible window, and using this display connection to choose the compressor. I can't guarantee an order since all GPUs are initialized in parallel, but only one of them (node:10.0) uses a visible window (see other thread). The FBO offscreen renderers also need a window for context handling, but these windows are not mapped. Alternatively, can we add another hack, e.g., let VGL ignore windows with a certain name? Cheers, Stefan. -- http://www.eyescale.ch http://www.equalizergraphics.com http://www.linkedin.com/in/eilemann ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
