On 11-03-01 03:37 PM, calvin.mor...@comcast.net wrote:
> Forgive the direct forward - I tried sending this message out to the
> list and it is either delayed or lost in mailing list limbo.
Heh, Mesa did recently move mailing lists to freedesktop.org for a
reason. :)
> ----- Forwarded Message -----
> From: "calvin morrow" <calvin.mor...@comcast.net>
> To: "VirtualGL Users" <virtualgl-users@lists.sourceforge.net>
> Sent: Tuesday, March 1, 2011 11:52:43 AM
> Subject: Re: [VirtualGL-Users] VirtualGL Linux wine crash in versions
> newer than 1.3.10
>
> I did some more testing based on comments here - hopefully there's some
> useful information since I know the methods were unorthodox to say the
> least.
>
> First, perhaps not helpful, but the error is reproduceable using a
> Cygwin XWin connection as the 2D server. It uses a mesa based GLX extension.
>
> Second, I did some basic testing using only a single host ... a Dell
> Latitude E6410 with a Quadro NVS 3100M using driver 260.19.21. I
> installed Wine 1.3.14 and downloaded the fr-041_debris.exe test file. I
> then connected to localhost with vglconnect.
>
> I ran tests using both "vglrun wine fr-041_debris.exe" and also setting
> the DISPLAY variable to the non-SSH forwarded :0.0 ("DISPLAY=:0.0
> VGL_TRACE=1 vglrun wine fr-041_debris.exe") and experienced the same
> error seen when using an intermediary 2D client. I collected the trace
> output and have attached it.
>
> I figured this test (however strange) would:
> a) remove a second X Server from being a variable [even though this is a
> very strange way of using VirtualGL]
> b) match the DISPLAY strings (such that the targets for both VGL and 3D
> rendering are the same [:0.0])
> c) Hopefully give more trace feedback since the loaded extensions should
> be identical (NV-GLX available since VGL target and client are the same
> X Server)
>
> The last trace message is a glXCreatePbuffer prior to the error. Could
> this be the op we've been hunting?
>
> [VGL] glXCreatePbuffer (dpy=0x7c48ce38(:0.0) config=0x00000077(0x77)
> attrib_list
> =[0x8041=0x0280 0x8040=0x01e0 0x801b=0x0001 ] pb=0x04400006 ) 0.000000 ms
> config=0x00000077(0x77) drawable=0x04400006 ) 0.000000 ms
> X Error of failed request: BadWindow (invalid Window parameter)
> Major opcode of failed request: 135 (GLX)
> Minor opcode of failed request: 16 (X_GLXVendorPrivate)
> Resource id in failed request: 0x4400006
> Serial number of failed request: 0
> Current serial number in output stream: 95
This matches what my WireShark trace saw (last request was
glXCreatePBuffer). In that hypothesis:
The minor op is wrong (CreatePbuffer is 27); plausible since the serial
is definitely wrong.
The BadWindow makes no sense at all, and isn't a valid error returned by
glXCreatePbuffer.
The resource id matches, since we know it is the pbuffer id.
I didn't have time to run against my Exceed onDemand display with GLX
off, but don't see it helping: the error is not returned by that X server.
I can only speculate, with DRC, on weirdness in the NVIDIA driver.
Normally in this case I'd take a trace and run it against a different
driver, but I wasn't able to run against a tracing X server and have
wine be happy. :(
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).
-Nathan
> ----- Original Message -----
> From: "DRC" <dcomman...@users.sourceforge.net>
> To: virtualgl-users@lists.sourceforge.net
> Sent: Tuesday, March 1, 2011 12:47:14 AM
> Subject: Re: [VirtualGL-Users] VirtualGL Linux wine crash in versions
> newer than 1.3.10
>
> On 2/28/11 6:20 PM, Nathan Kidd wrote:
> > On 11-02-28 07:04 PM, DRC wrote:
> >> I'm not following how you ascertained that the issue was between WINE
> >> and the 3D X server.
> >
> > Sorry, I didn't mention that part. I ran against an in-house X server
> > with tracing enabled and examined the trace. No GLX, and more
> > importantly, no X errors returned at all. Therefore it had to be the 3D
> > X Server.
>
> I've encountered situations before in which a particular GLX call will
> only be sent to the 2D X server if the GLX extension is detected on it.
> I can't easily imagine a scenario in which a GLX call would be sent to
> the 3D X server unless VirtualGL was sending it. If the error is
> reproducible with Exceed 3D, it would be a worthwhile experiment to try
> disabling GLX support in the latter and see if the error goes away.
>
> Something else I've started to notice in recent nVidia drivers is that,
> if I run remotely using the VGL Transport, I get the following warning:
>
> Xlib: extension "NV-GLX" missing on display "{client_display}".
>
> The nVidia drivers do some hooking of functions at the low level, so
> it's possible that they are hooking an Xlib call and making a GLX call
> from within the body of the Xlib call. They may very well be using a
> private symbol for the hooked GLX call, or the dynamic link order may be
> such that VirtualGL is not catching it.
>
------------------------------------------------------------------------------
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
