Re: [VirtualGL-Devel] Fwd: [ virtualgl-Bugs-3463913 ] Multi-GPU compatibility
3D Without Boundaries
Brought to you by:
dcommander
From: DRC <dco...@us...> - 2011-12-23 15:22:18
|
On 12/23/11 2:54 AM, Stefan Eilemann wrote: > Since I cant comment on a closed bug, I'll do it here: <sigh> I apologize for the lameness of the SourceForge bug tracker. "Close comment posting" is unchecked, so I'm not sure why it isn't letting you comment. In theory at least, it should still be open for comments, even though it's closed. >> 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. It already does that. The first call to glXMakeCurrent() with a window ID should cause VGL to pick a default image transport. The default image transport is set in the constructor of pbwin, based on the Display * passed to glXMake[Context]Current(). pbwin is instantiated within the body of glXMake[Context]Current() if a window is passed to that function and the window does not already have a pbwin instance attached to it (which is the case if that window has not been made current before.) However, if you're calling glXMakeCurrent() on non-visible windows (why?), then that would explain the behavior you're seeing. |