Re: [VirtualGL-Users] Fwd: VirtualGL Linux wine crash in versions newer than 1.3.10

[Nathan K. <nat...@sp...>]

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