On 11-03-02 03:01 AM, DRC wrote: > On 3/1/11 3:02 PM, Nathan Kidd wrote: >> This matches what my WireShark trace saw (last request was >> glXCreatePBuffer). In that hypothesis: > > VGL handles glXCreatePbuffer() with no problems (I even test for that in > rrfakerut.) In the trace, that function completes without error, so it > must be a subsequent call that is causing the problem.
I was imagining that the NVIDIA driver sees that call and does other stuff under the hood based on it. >> Hmmm, actually, I have an idea, based on what DRC said before about >> NV-GLX. When an NV-GLX libGL talks to a server that supports NV-GLX it >> has additional traffic (major opcode 139 on my server). This must be >> where the error comes from and why nothing decoded it. Since NV-GLX is >> a private protocol, we don't have any VGL hooks for it. >> >> Experiment for whoever gets time first: in VGL disable NV-GLX in the X >> extension strings and see if that fixes it (since client libGL no longer >> is able to do NV-GLX traffic). > > Except that the warning is printed precisely because the NV-GLX > extension can't be found on the 2D X server, so explicitly disabling it > in VirtualGL's interposed version of XQueryExtension() wouldn't affect > that outcome. Also, I get the same warning when I run any GLX > application indirectly (without VGL) from my Linux/nVidia 260.19.36 > machine to a remote X server that lacks NV-GLX, so this may just be a > red herring and have nothing to do with the problem at hand. When I said "Based on" what you had said I really should have said "reminds me" of NV-GLX's existence. The warning isn't the issue, but the presence of the extension is, based on my other mail. > I still think it's an uninterposed GLX call slipping through. nVidia > has, in the past, been known to call GLX functions (sometimes private > ones) from within the bodies of X11 functions (I don't know enough about > X11 driver architecture to say how they do this, but I guarantee you > it's happened.) I agree it is like you're saying, it's something VGL doesn't catch, but I think it's something sent over NV-GLX (or less likely: NV-CONTROL predicated on NV-GLX's existence) not GLX. I've never seen a spec for NV-GLX, but it could be the driver sends X protocol directly without any API to interpose. -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 VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
