Re: [Chromium-dev] Visbits changes have broken many things

[Brian P. <bri...@tu...>]

Mike Houston wrote:
> Okay, if I explicitly setup the default visuals everywhere to match the 
> crutserver, I can get crut_fan.conf to work.  After the changes to 
> visbits and getting psubmit to create it's own window, we now get an app 
> window and a render spu window.  If I set render_to_app_window for the 
> applications, everything gets routed to the crutwindow and I get trash 
> rendered.

I'm not sure I understand.  Could I see your .conf file?


> What happens on Nvidia when running crut_fan?

It just works.


> Things used to work 
> perfectly before for me before the last round of changes.  Now on ATI, I 
> have to set use_glxchoosevisual to 0 (probably ATI's fault, but I'm not 
> convinced just yet) and define the default visual for *every* render spu 
> (or derived spu) to match the final render spu.  There has to be a 
> better way to handle this.  We should be able to detect a difference in 
> visuals and adapt...

Perhaps we should try to recreate the GLX context with a new visual if 
the initial context's visual doesn't match the CRUT window's visual. 
I think that might work.  I'll look into it.


> I'm just trying to get things running again so I 
> can go back to the MPI layer next week.

Try the attached patch to renderspu_glx.c.  It might fix the segfault 
that happens after trying to issue GL commands after a failed 
MakeCurrent.  Though, OpenGL should not crash if there's no current 
context.

-Brian


> -Mike
> 
> Mike Houston wrote:
> 
>>
>>
>> Brian Paul wrote:
>>
>>>
>>> This basically means that GLUT chose visual 0x27 for the window it 
>>> created, given the flags passed to glutInitDisplayMode() while 
>>> Chromium's render SPU choose visual 0x29 for its GLX rendering 
>>> context, given the spu's default visual flags.
>>>
>>> The thing is, that's a recoverable situation.  Note that this is 
>>> happening when the default window/context is being created.  Later, 
>>> when crMakeCurrent() is called in psubmit_crut.c, the context should 
>>> have a visual which matches the GLUT window.
>>>
>>> I think I may have something: look at psubmit_crut.c, line 92:
>>>
>>> static int visual = CR_RGB_BIT | CR_DEPTH_BIT | CR_DOUBLE_BIT;
>>>
>>> But in crutserver/main.c line 316 we're asking for stencil:
>>>
>>>     glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA | 
>>> GLUT_STENCIL);
>>>
>>>
>>> Could you try adding CR_STENCIL_BIT to the visual initialization?
>>>
>>>
>> Still no love.  The visuals still didn't change on the server side.  
>> The change to psubmit_crut modifies the application side's visbits, 
>> but the error I'm seeing is on the cr/crutserver side.
>>
>>>
>>>
>>>> CR Debug(spire:19914): Render SPU: GL_VENDOR:   (null)
>>>> CR Debug(spire:19914): Render SPU: GL_RENDERER: (null)
>>>> CR Debug(spire:19914): Render SPU: GL_VERSION:  (null)
>>>> CR Debug(spire:19914): Render SPU: ---------- End of Init -------------
>>>> CR Debug(spire:19914): CRServer: my clients: 1 tcpip 2
>>>> CR Debug(spire:19914): In crNetAcceptClient( protocol="tcpip" 
>>>> port=7000 mtu=1048 576 )
>>>> CR Warning(spire:19914): Couldn't find the CRMOTHERSHIP environment 
>>>> variable, de faulting to localhost
>>>> CR Debug(spire:19914): In crNetConnectToServer( "localhost", 
>>>> port=10000, mtu=809 6, broker=0 )
>>>> CR Debug(spire:19914): Connecting to server spire.stanford.edu on 
>>>> port 10000, wi th protocol tcpip
>>>> CR Debug(spire:19914): Done connecting to server localhost (swapping=0)
>>>> CR Debug(spire:19914): Accepted connection from "spire".
>>>> CR Debug(spire:19914): No tiling information for server!
>>>> CR Info(spire:19914): Total output dimensions = (0, 0)
>>>> CR Debug(spire:19914): Adding to the run queue: client=0x8290d18 
>>>> number=0 count=1
>>>> CR Debug(spire:19914): Buffer pool 0x811d910 was empty; allocated 
>>>> new 1048596 byte buffer.
>>>> Segmentation fault (core dumped)
>>>
>>>
>>>
>>>
>>> Can you determine where this crash is coming from?
>>>
>> There is a stack smash, so I'm not sure the trace is actually valid:
>>
>> #0  0x00000000 in ?? ()
>> #1  0x4300c6f3 in glBindBufferARB () from /usr/lib/libGL.so
>> #2  0x0806585d in crStateBufferObjectSwitch (bb=0x80cfab0, 
>> bitID=0xaee7d00c,
>>    fromCtx=0xb7dfc008, toCtx=0xaee7d008) at state_bufferobject.c:702
>> #3  0x080a0643 in crStateSwitchContext (from=0xb7dfc008, to=0xaee7d008)
>>    at state_diff.c:162
>> #4  0x0807a2c9 in crStateMakeCurrent (ctx=0xaee7d008) at state_init.c:299
>> #5  0x08055948 in crServerSerializeRemoteStreams () at 
>> server_stream.c:307
>> #6  0x0804a3bb in CRServerMain (argc=1, argv=0xbfffd8c4) at 
>> server_main.c:223
>> #7  0x08049ee2 in main (argc=1, argv=0xbfffd8c4) at main.c:22
>>
>> What's odd is that running with crutserver, when we can't bind the 
>> context, we get a completely bogus link into libgl, hence:
>>
>> CR Warning(spire:25274): Render SPU: Can't bind context 0 to 
>> CRUT/native window 0x3600001 because of different X visuals (0x27 != 
>> 0x29)!
>> CR Debug(spire:25274): Render SPU: GL_VENDOR:   (null)
>> CR Debug(spire:25274): Render SPU: GL_RENDERER: (null)
>> CR Debug(spire:25274): Render SPU: GL_VERSION:  (null)
>> CR Debug(spire:25274): Render SPU: ---------- End of Init -------------
>>
>> I'll try setting a default visual for the renderspu that matches the 
>> crutserver init.
>>
>> -Mike
>>