Re: Visbits changes have broken many things

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