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 ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
