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

[Mike H. <mho...@gr...>]

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.

What happens on Nvidia when running crut_fan?  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...  I'm just trying to get things running again so I 
can go back to the MPI layer next week.

-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
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev