I was able to actually reproduce this, completely by accident. I use a VirtualBox VM to build and test VGL on Solaris, and since the 3D acceleration support in VBox doesn't support Pbuffers, I have to use the root display of a remote Linux machine as my 3D X server and set VGL_DISPLAY accordingly. For some reason, this exposed the bug, possibly because of the mismatch between client and server GLX implementations, or perhaps because the client in this case uses an older nVidia implementation. The VM has 100.14.19 of the nVidia drivers installed-- they don't work in the VM, but I have to link against the nVidia libGL because neither the VirtualBox nor Mesa implementations have all of the functions VGL needs.
The circumstances by which it would choose the 128-bit StaticGray config were odd. GLXGears wouldn't do it, because it was selecting GLX_[RED|GREEN|BLUE]_SIZE=1, but GLXSpheres would, because it was selecting GLX_[RED|GREEN|BLUE]_SIZE=8. I was able to work around that by adding GLX_X_VISUAL_TYPE, GLX_TRUE_COLOR to the attributes passed to glXChooseFBConfig() in glxvisual.cpp. Having reproduced the problem in that manner, I hacked GLXSpheres so that it used XGetVisualInfo() to obtain a visual rather than glXChooseVisual(), and this reproduced the original incarnation of the bug in _MatchConfig(). GLX_X_VISUAL_TYPE, GLX_TRUE_COLOR also worked there, but then it was trying to give me a FB Config with no depth buffer, so I had to add GLX_DEPTH_SIZE, 1 as well. On 3/31/11 4:19 PM, Nathan Kidd wrote: > On 11-03-29 07:08 PM, DRC wrote: >> On 3/29/11 12:35 PM, Nathan Kidd wrote: >>> On 11-03-28 10:11 PM, DRC wrote: >>> I've attached a file that maybe does what you're thinking of: > ... >>> To be clear, the "problem" is no variety of visual attribs. (The Ansoft >>> HFSS problem can only be seen with a specific NVIDIA driver and video >>> card.) >> >> In TurboVNC, the output is (as expected) one visual, but it appears to >> have reasonable attribs: > ... > > (Of course that test will only give interesting results if you had > multiple visuals available (E.g. your local X server.) and ran > getconfig with and without the patch I sent.) > >> IMHO, the real problem is that certain nVidia drivers aren't picking an >> appropriate default whenever _MatchConfig() requests a FB config with >> specifying things such as the visual type or the depth buffer size. > > This is the real problem with the specific case I'm looking at, though > not from a "make VirtualGL as theoretically compatible as possible" > perspective. I recognize, however, that in the face of potential > breakage the latter may not be a goal at all. > >>> I'm not familiar with how TurboVNC sets up screens/visuals, but what >>> Exceed onDemand does is export a number of visuals specifically to >>> provide the variety for GLX to work with. From a 2D X perspective they >>> have the same attribs, but on the GLX side they're mapped to different >>> FBConfigs/PixelFormats. EoD has to check what the actual desktop >>> machine's card can support, in case of desktop-side rendering. Since >>> TurboVNC only supports server-side rendering could it blindly allocate a >>> handful visuals which would be enough to to fill in a useful variety of >>> GLX visual types? >> >> It's not just TurboVNC. Many X proxies provide only 1 or 2 visuals. >> >> >>> I believe making _MatchConfig include an explicit GLX_DEPTH_SIZE attrib >>> would be sufficient to fix Anosft HFSS (with this specific driver/card >>> combo) *and* 95% of every application that needs this fix. (What app >>> requires to *not* have a depth buffer?) >>> >>> The reason I didn't just do that is because I didn't want to push a fix >>> just for my problem, but provide a general solution for every kind of >>> similar issue. Maybe one day another driver will require another default >>> to be explicitly specified, maybe another app requires specific stencil >>> or aux buffers. Without the patch it can't choose them, though >>> as you point out, TurboVNC specifically needs to advertise more visuals >>> for this to work with that specific proxy. >> >> It's been my experience that trying to apply general solutions to >> specific problems with VirtualGL tends to break things. Unfortunately, >> there are a lot of "stupid application tricks" out there that we've had >> to work around over the years, and rrfakerut tests some of them but not >> all. Thus, I have to be really conservative about applying anything >> disruptive to the code, because there's usually no way to test whether >> I've broken something except to release it and let the users tell me. >> >> I could modify TurboVNC to advertise more visuals, but I'd have a lot of >> splainin' to do if I tried to do the same thing to TigerVNC, and they >> probably wouldn't accept the patch. I have no control over any other X >> proxies. > > I'm content to bow to your experience in the matter :) if somebody comes > along in the future with an app that manually chooses its visual via > glXGetConfig and requires say, a stencil buffer, we could always > introduce a "VGL_DEFAULTCONFIGWITHSTENCIL" option to modify the attrib > list like your patch below does. This approach would work with any X > proxy, regardless of number of visuals advertised. > >> I'm attaching a proposed patch, which causes _MatchConfig() to specify a >> 24-bit depth buffer and a true color visual type. Please test this >> against the specific apps that are broken at the moment, and if it fixes >> those, then I think that's what we need to do for now. > > I'm waiting to hear back on this test but hopefully will get a result soon. > > -Nathan ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
