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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

That fixes readback.conf, but now crut programs are borked.  For 
example, crut_fan.conf.  When crserver tries to bind to the crutserver 
window, I now get this on the crserver side:

CR Debug(spire:19914): Looking for the system's OpenGL library...
CR Debug(spire:19914): Found it in default path.
CR Debug(spire:19914): Render SPU: Creating default window 
(visBits=0x25, id=0)
CR Debug(spire:19914): Render SPU: Opening display :0.0
CR Debug(spire:19914): Render SPU: Looks like we have GLX
CR Debug(spire:19914): Render SPU: Chose visual id=0x29: RGBA=(8,8,8,8) 
Z=24 ste ncil=0 double=1 stereo=0 accum=(0,0,0,0)
CR Debug(spire:19914): Render SPU: Created window 0x3600001 on display 
:0.0, Xvi sual 0x29
CR Debug(spire:19914): Render SPU: actual window x, y, width, height: 
500, 500, 400, 400
CR Debug(spire:19914): Render SPU: WindowCreate returned 0 (0=normal)
CR Debug(spire:19914): Render SPU: Creating default context, visBits=0x25
CR Debug(spire:19914): Render SPU: Created DIRECT context (0) on display 
:0.0, X visual 0x29
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): Render SPU: using CRUT drawable: 0x3200001
CR Warning(spire:19914): Render SPU: Can't bind context 0 to CRUT/native 
window 0x3200001 because of different X visuals (0x27 != 0x29)!
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)

This visuals are now unhappy.  I've tried setting several default 
visuals for the renderspu on the server side, but no luck just yet.  
I'll play this things a little bit more.

-Mike

Brian Paul wrote:

>
> Mike, on the readback SPU, try spu.Conf('use_glxchoosevisual', 0)
>
> This tells the Render SPU to not call glXChooseVisual.  For some 
> reason, the call doesn't get resolved to the ATI libGL routine, but 
> instead, to the faker's glXChooseVisual.  (Of course, this only 
> happens when the render/readback SPU is hosted by the app node.)
>
> I think the problem is ATI's libGL wasn't linked with the -Bsymbolic 
> option.  But that doesn't explain why glXGetConfig works.  Strange.
>
> The code path for use_glxchoosevisual = 0 was previously the default 
> in the Render SPU, but it was causing problems with the NVIDIA drivers 
> in particular configurations.  So, the bug work-around is now chosen 
> with the config option.
>
> I hope that fixes things for you.
>
> -Brian
>
>
>
>
> Mike Houston wrote:
>
>> This is on Linux, on ATI hardware with 3.14.6 as well as the newest 
>> release.  When I get back in on Monday, I'll take a deeper look and 
>> send you the output.  It is bailing out as soon as the default 
>> context is being created.  It's trying for visual 0x27 (RGBA, double, 
>> Z) and can't get it.  Sort-first apps work just fine as well as the 
>> sort last apps running locally.
>>
>> -Mike
>>
>> Brian Paul wrote:
>>
>>> Mike Houston wrote:
>>>
>>>> The changes to visbits seem to have broken all sort-last 
>>>> rendering.  As a simple example, try readback.conf with atlantis or 
>>>> psubmit_last.conf.  We seem to complain that we can't get the 
>>>> necessary visual for anything...  Backing off to before the large 
>>>> stack of changes to the visbits gets everything working happy again.
>>>>
>>>> Can someone else please verify this behavior before we start trying 
>>>> to track this down?
>>>
>>>
>>>
>>>
>>>
>>> Hmmm.  Both those demos work for me.  And my recent visBits changes 
>>> have overall solved several problems for me, so they can't be 
>>> totally wrong.
>>>
>>> Could I see all the debug output from the app/server nodes?
>>>
>>> Is this on Linux or Windows?
>>>
>>> Which cards/drivers?
>>>
>>> -Brian
>>>
>>> PS: I found a one-line check-in mistake in renderspu_glx.c that'll 
>>> I'll fix, but it doesn't change anything here.
>>>
>>>
>>> -------------------------------------------------------
>>> 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
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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
>>
>