On 11-02-26 08:19 PM, DRC wrote: > Unless I'm mistaken, in order for an app to experience this problem, it > would have to: > > (1) Obtain vis1 using some means other than glXChooseVisual(): > (a) Using XGetVisualInfo(), in which case the 3D app obviously > doesn't care about the visual's 3D capabilities. In this case, > _MatchConfig() will assign a reasonable FB config. > (b) Iterating through the available visuals using glXGetConfig(). > In this case, _MatchConfig() will assign an FB config to the visual on > the first call to glXGetConfig() (further discussion on this once I look > at your other patch.)
Yes, I think this is correct. > (2) Create a GLX context using vis1. Yes. > (3) Call glXChooseVisual() to obtain a visual with specific > capabilities. Assuming that the visual returned has the same ID as > vis1, VirtualGL will re-hash the visual ID to an FB config that fits the > desired GLX attributes. Yes. > (4) Specifically check the visual ID of vis1 against the visual ID of > vis2 and avoid calling glXCreateContext() if they match. Yes. > I know of at least one app that does (1)(b), (2), and (3), but since the > app subsequently calls glXCreateContext() with vis2, it still works > fine. I wouldn't want to print a warning unless the app was doing (4), > and there's no way to ascertain that. Right, there's no way for us to know the application's intention for querying for the visual or what internal logic it does afterward. Would you be ok to move it to a trace-only message? If such an app ever did exist and we were trying to track down weird drawing problems it would technically be possible to notice that the same visual was mapped to different configs by carefully scanning the existing trace logs, but an explicit warning would be helpful, IMO. I'm not dearly attached to the patch, however. If you think I'm being too paranoid and want to drop this patch I won't complain. :) -Nathan > On 2/25/11 2:23 PM, Nathan Kidd wrote: >> An app would almost have to try on purpose for this to be a problem, >> but it could be hard to track down: >> ctx1 = glXCreateContext(vis1); (_MatchConfig assigns to config1, >> depthbuf 24) >> then >> vis2 = glXChooseVisual(some attribs, depth 0 ); (assigns config2 >> depthbuf 0) >> >> Then notice vis1.visualid == vis2.visualid, therefore no need to create >> a new context to draw with a 0-size depth buffer, but though visualids >> are the same they are mapped to very different server configs. >> >> Ideally MatchConfig and glXChooseVisual would use the same mechanism so >> they could never disagree, but because one uses arbitrary attribs, the >> other doesn't, and both are subject to the whims of glXChooseFBConfig I >> think the only way to guarantee a match is to do the config selection >> ourselves; too much code for just a theoretical edge case. >> >> Why not just make glXChooseVisual return what _MatchConfig already >> chose? It could be done, but I left a warning instead, thinking the >> greater danger is the app getting a config it doesn't like if we ignore >> the explicit attributes passed in. (__vglMatchVisual() is fairly loose.) >> >> -Nathan ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
