In all of my recent testing with only a single X Server, the 3D Server == 2D
Server with only VGL inbetween. The DISPLAY variable is set to :0.0 (and VGL
rendering to :0.0) with only unix sockets + loopback in use (for VGL SSH
connection) and the crash still occurs.
Since the environment variables are identical in this test case, I can't see
where nVidia would be pulling anything to change its behavior. It seems to me
its anyone's guess about why the glXSwapIntervalSGI function dies, so hopefully
your coworker can shed some light.
Calvin
----- Original Message -----
From: "DRC" <dcomman...@users.sourceforge.net>
To: "calvin morrow" <calvin.mor...@comcast.net>
Cc: "Nathan Kidd" <nathan...@spicycrypto.ca>, "VirtualGL Users"
<virtualgl-users@lists.sourceforge.net>
Sent: Wednesday, March 2, 2011 3:14:56 PM
Subject: Re: [VirtualGL-Users] VirtualGL Linux wine crash in versions newer
than 1.3.10
Bingo.
Apparently nVidia is trying to outsmart us yet again and is somehow
making a determination in the underlying GLX library that it needs to
send glXSwapIntervalSGI() over the wire rather than to the display on
which the GLX context has been established (bad, bad nVidia! Bad! No
treat for you!)
I interposed the call and made it a no-op, and everything works now.
I'm not sure if this call has any real meaning with Pbuffer rendering
anyhow, so it might be reasonable to just leave it as a no-op in
VirtualGL. Any comments on that?
In the body of my interposed function, I tried to do a setenv() and
repoint the DISPLAY environment variable temporarily to
DisplayString(_localdpy), on the hunch that maybe nVidia's version of
the function is simply reading the display from the environment. No
such luck, however. I'm not sure where it's getting the display handle
from.
I asked one of my co-workers who now works for nVidia for his opinion.
I'd like to find out why the underlying function is deciding that it
needs to send a remote GLX request, in case there are other GLX
functions that are doing the same thing. It'd be better to work around
all of them at once instead of playing whack-a-mole with each one as it
pops up in a specific app.
On 3/2/11 3:27 PM, calvin.mor...@comcast.net wrote:
> Ok - did some tracing through Wine. The winedebug_wgl_reg.txt.gz was
> run using "WINEDEBUG=trace+wgl wine fr-041_debris.exe", and
> windebug_wgl_vgl.txt.gz was run except using vglrun "WINEDEBUG=trace+wgl
> vglrun wine fr-041_debris.exe". Note: I killed the ...reg.txt.gz log
> after it started to output the loading window (since the vglrun never
> makes it that far).
>
> Tail of trace logfile:
>
> trace:wgl:X11DRV_wglMakeCurrent make current for dis 0x7c4967c0,
> drawable 0x4400007, ctx 0x7c4dcae0
> trace:wgl:X11DRV_wglMakeCurrent returning True
> trace:wgl:X11DRV_wglSwapIntervalEXT (1)
> 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: 0x2a00006
> Serial number of failed request: 0
> Current serial number in output stream: 95
>
> Listed under: Changes since 1.3.10:
> wined3d: Handle the swapchain presentation interval with
> wglSwapIntervalEXT.
>
> Coincidence?
>
> Someone more knowledgeable will have to verify, but it seems that in the
> Wine source under X11DRV_wglSwapIntervalEXT(int interval) with an
> interval of 1 would execute the following code:
>
> if (pglXSwapIntervalSGI)
> {
> wine_tsx11_lock();
> ret = !pglXSwapIntervalSGI(interval);
> wine_tsx11_unlock();
> }
>
> I believe this counts as a "X_GLXVendorPrivate" opcode, does it not?
>
> Calvin
>
> ----- Original 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
>
>
> ----- 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
>
> ------------------------------------------------------------------------------
>
> 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
------------------------------------------------------------------------------
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
