chromium-dev — For developers of the Chromium framework or SPU's

[Chromium-dev] Problems with shutdown of crserver for non-tcpip connections

[Joel W. <we...@st...>]

Hi folks;
  I'm encountering a problem managing the crserver processes for configs in 
which I use the teac network mechanism; I think it will also be seen in things 
like GM.  When I spawn the crserver I keep track of its PID, and when I want 
it to terminate I send a TERM signal to that PID.  Fair enough; the process 
that got that signal terminates, running through the 'teardown' routine in the 
crserverlib code.
  The problem is, by this time the crserver has spawned 2 child processes.  I 
believe they are actually other threads, but I'm not sure- I know they are not 
being created with crSpawn().  One of those threads is very, very busy doing a 
wait loop, waiting for messages on my high-bandwidth network.  That process, 
and the third process which is its child, do *not* die when their parent (the 
originally spawned process) gets the TERM signal.
  Can anyone confirm for me that these are threads, and tell me which bit of 
code is likely to be spawning them?  Are their PIDs or thread IDs getting 
saved anywhere?  I can modify the teardown procedure to kill them if I have 
their names, but I can't simply kill the whole process group- that kills 
innocent bystanders.

Thanks,
-Joel
 we...@ps...

Re: [Chromium-dev] Re: Pixel-image compression within Chromium?

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

I checked in your patch, Bill.  Thanks!

-Brian


Bill Feth wrote:
> Hi Brian,
> 
> I worked with Alicia to fix the byte-swapping problem she was seeing. The
> code in packer/pack_swap_texture.c was not byte swapping the texture data
> when it was sent from a little-endian app-node to a big-endian crserver.
> 
> She had a test application that used gluBuild2DMipmaps, which converted
> the UNSIGNED_BYTE texture to UNSIGNED_SHORT and then generated
> UNSIGNED_SHORT mipmap levels. None of the texture data was being
> byte-swapped by Chromium. The top mipmap level looked fine because the
> pixel values were all values like 0xA0A0 and 0xB7B7 (an artifact of the
> byte->short conversion). But the mipmap levels were mostly values like
> 0xB7FC, which look very wrong when they are not swapped.
> 
> I have attached a patch; it utilizes byte-swapping code recently added to
> util/pixel.c for handling GL_(UN)PACK_SWAP_BYTES. I've tested that it at
> least works in the Windows->IRIX direction for 2D textures, but it should
> apply to more general cases.
> 
> Would you be able to review and apply the patch?
> Thanks,
> Bill
> 
> 
> -----Original Message-----
> Date: Fri, 14 Jan 2005 07:40:18 -0700
> From: Brian Paul <bri...@tu...>
> To: aac...@ad...
> CC: chr...@li...
> Subject: [Chromium-dev] Re: Pixel-image compression within Chromium?
> 
> 
> Do you suspect it's texture images that are the source of the problem? 
>   Or glDrawPixels?  You mentioned images in your post.
> 
> Textures are typically specified in GL_RGB or GL_RGBA format with
> GLubytes.  Since those are byte-sized components, there shouldn't be any
> endian issues.
> 
> If you see the problem with any small, simple GL demos (like the redbook
> or GLUT demos) that would help narrow it down.  Even a screen shot showing
> the problem could give us a clue.
> 
> Chromium doesn't normally do any image compression.
> 
> -Brian
> 
> 
> aac...@ad... wrote:
> 
>>Hello,
>>
>>I posted something about this problem before, but have not gotten any
> 
> response.  To re-iterate, certain colors on certain applications run
> through Chromium from a Windows Box (mothership and crappfaker) to a
> crserver running with OMP (like DMX) on an SGI Onyx 4 running IRIX do not
> appear correctly.   
> 
>>One problem is that the Chromium Print-SPU doesn't include data in its
> 
> output; only the address of the texture image in memory, so I can't see
> the data that the application's sending to Chromium.
> 
>>For those of you who know the inner workings of Chromium, is it 
>>possible
> 
> that Chromium is doing some kind of pixel-image compression, and there are
> bit errors being introduced because of that?  If it does do pixel-image
> compression, is it possible to turn this compression off??
> 
>>Thanks for your help,
>>Alicia

[Chromium-dev] Re: Pixel-image compression within Chromium?

[Bill F. <fe...@sg...>]

Hi Brian,

I worked with Alicia to fix the byte-swapping problem she was seeing. The
code in packer/pack_swap_texture.c was not byte swapping the texture data
when it was sent from a little-endian app-node to a big-endian crserver.

She had a test application that used gluBuild2DMipmaps, which converted
the UNSIGNED_BYTE texture to UNSIGNED_SHORT and then generated
UNSIGNED_SHORT mipmap levels. None of the texture data was being
byte-swapped by Chromium. The top mipmap level looked fine because the
pixel values were all values like 0xA0A0 and 0xB7B7 (an artifact of the
byte->short conversion). But the mipmap levels were mostly values like
0xB7FC, which look very wrong when they are not swapped.

I have attached a patch; it utilizes byte-swapping code recently added to
util/pixel.c for handling GL_(UN)PACK_SWAP_BYTES. I've tested that it at
least works in the Windows->IRIX direction for 2D textures, but it should
apply to more general cases.

Would you be able to review and apply the patch?
Thanks,
Bill


-----Original Message-----
Date: Fri, 14 Jan 2005 07:40:18 -0700
From: Brian Paul <bri...@tu...>
To: aac...@ad...
CC: chr...@li...
Subject: [Chromium-dev] Re: Pixel-image compression within Chromium?


Do you suspect it's texture images that are the source of the problem? 
  Or glDrawPixels?  You mentioned images in your post.

Textures are typically specified in GL_RGB or GL_RGBA format with
GLubytes.  Since those are byte-sized components, there shouldn't be any
endian issues.

If you see the problem with any small, simple GL demos (like the redbook
or GLUT demos) that would help narrow it down.  Even a screen shot showing
the problem could give us a clue.

Chromium doesn't normally do any image compression.

-Brian


aac...@ad... wrote:
> Hello,
> 
> I posted something about this problem before, but have not gotten any
response.  To re-iterate, certain colors on certain applications run
through Chromium from a Windows Box (mothership and crappfaker) to a
crserver running with OMP (like DMX) on an SGI Onyx 4 running IRIX do not
appear correctly.   
> 
> One problem is that the Chromium Print-SPU doesn't include data in its
output; only the address of the texture image in memory, so I can't see
the data that the application's sending to Chromium.
> 
> For those of you who know the inner workings of Chromium, is it 
> possible
that Chromium is doing some kind of pixel-image compression, and there are
bit errors being introduced because of that?  If it does do pixel-image
compression, is it possible to turn this compression off??
> 
> Thanks for your help,
> Alicia

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

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

Brian Paul wrote:

> 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? 


import sys
sys.path.append( "../server" )
from mothership import *

Demo = 'psubmit_crut'

Demo = os.path.join(crbindir, Demo)

# Can render/readback windows by dynamically resized?
resizable = '1'

# Set up the server node
servernode1 = CRNetworkNode( )
# Note: each client has the -swap flag and we tell the server to only
# do one SwapBuffers here.
servernode1.Conf( 'only_swap_once', 1 )
servernode1.Conf( 'shared_windows', 1 )
renderspu = SPU( 'render' )
renderspu.Conf( 'window_geometry', [500, 500, 400, 400] )
renderspu.Conf('resizable', resizable)
renderspu.Conf('render_to_app_window', 1 )
renderspu.Conf('render_to_crut_window', 1 )
renderspu.Conf('default_visual', 'rgb, double, depth, stencil')
# only specifying visual to work-around ATI FireGL problem
servernode1.AddSPU( renderspu )

#create a crutserver
crutserver = CRUTServerNode(  )
crutserver.Conf('window_geometry', [100, 100, 400, 400] )

# Set up first app/client node
appnode1 = CRApplicationNode(  )
appnode1.SetApplication( '%s -rank 0 -size 2 -clear -swap' % Demo )
appnode1.StartDir( crbindir )
spu = SPU('readback')
spu.Conf('window_geometry', [0, 0, 400, 400])
spu.Conf('use_glxchoosevisual', 0)
spu.Conf('extract_depth', '1')
spu.Conf('resizable', resizable)
spu.Conf('render_to_app_window', 1)
spu.Conf('default_visual', 'rgb, double, depth, stencil')
appnode1.AddSPU( spu )
spu = SPU('pack')
appnode1.AddSPU( spu )
spu.AddServer( servernode1, 'tcpip' )

#let's define a CRUTserver as anything that will feed us events
#this way we can create either a ring or a fan configuration
appnode1.AddCRUTServer( crutserver , protocol='tcpip', port=9000 )


# Set up second app/client node
appnode2 = CRApplicationNode( )
appnode2.SetApplication( '%s -rank 1 -size 2 -clear -swap' % Demo )
appnode2.StartDir( crbindir )
spu = SPU('readback')
spu.Conf('window_geometry', [420, 0, 400, 400])
spu.Conf('use_glxchoosevisual', 0)
spu.Conf('extract_depth', '1')
spu.Conf('resizable', resizable)
spu.Conf('default_visual', 'rgb, double, depth, stencil')
spu.Conf( 'render_to_app_window', 1 )
appnode2.AddSPU( spu )
spu = SPU('pack')
appnode2.AddSPU( spu )
spu.AddServer( servernode1, 'tcpip' )

appnode2.AddCRUTServer( crutserver, protocol='tcpip', port=9000 )

cr = CR()
cr.MTU( 10*1024*1024 )
# Note: adding nodes in the order in which they must be started!
cr.AddNode( appnode1 )
cr.AddNode( appnode2 )
cr.AddNode( crutserver )
cr.AddNode( servernode1 )
cr.Go()

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

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

Brian Paul wrote:
> Mike Houston wrote:

> 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.

OK, here's a patch to do that.  Apply after the previous patch.

-Brian

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
>>

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

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

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

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

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

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

Mike Houston wrote:
> 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)!

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?




> 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?



> 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


> 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
>>>
>>
> 

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

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

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
>>
>

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

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

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
> 

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

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

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

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

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

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.

[Chromium-dev] Visbits changes have broken many things

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

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?

Thanks,
-Mike

[Chromium-dev] Forget about my requests so far

[Thomas A. <ta...@mp...>]

<FONT face=3D"Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=
=3D2><DIV>Have been solved.</DIV><DIV>Sorry for bothering.</DIV><DIV>&nbsp;=
</DIV><DIV>1.) Tiled display: Used VNC for starting crserver on clients whi=
ch </DIV><DIV>trashed the performance.</DIV><DIV>2.) Forgot the array spu t=
o filter vertex array.</DIV><DIV>Everything is working fine now.</DIV><DIV>=
Best, Tom<BR></DIV><DIV>--<BR>Thomas Annen,<BR>Computer Graphics Group - AG=
4<BR>Max-Planck-Institut Informatik<BR>Stuhlsatzenhausweg 85, 66123 Saarbr=
=C3=BCcken, Germany<BR>Phone: +49 681 9325-426 Fax: +49 681 9325-499<BR><A =
href=3D"mailto:ta...@mp..." target=3Dblank >ta...@mp...</=
A><BR></DIV></FONT>=

[Chromium-dev] Tilesort and hiddenline

[Thomas A. <ta...@mp...>]

<FONT face=3D"Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=
=3D2><DIV>Hi there.</DIV><DIV>&nbsp;</DIV><DIV>I am trying to run Quake3 on=
 a displa wall.</DIV><DIV>I have a problem. I wanted to have the following:=
</DIV><DIV>1&nbsp;app node (having a hiddenline -&gt; tilesort chain)</DIV>=
<DIV>8 server nodes with just a render chain.</DIV><DIV>This works fine for=
 atlantis but nor for Quake3</DIV><DIV>Then if I try to run Quake locally w=
ith:</DIV><DIV>app: pack and server: hiddenline-&gt;render chain</DIV><DIV>=
it works.</DIV><DIV>When I do the same with the wall rendering,</DIV><DIV>m=
eaning bringing the hiddenline spu on the</DIV><DIV>server side it works pa=
tially. Not all the triangles</DIV><DIV>are rendered even when using broadc=
ast.</DIV><DIV>An idea.</DIV><DIV>Originally I wanted to leave the hiddenli=
ne spu at the</DIV><DIV>app side, because&nbsp; wanted to modify it for mul=
tipass</DIV><DIV>rendering.</DIV><DIV>&nbsp;</DIV><DIV>Can anybody give me =
some advice please?</DIV><DIV>&nbsp;</DIV><DIV>Thansk a lot.</DIV><DIV>Best=
, Tom<BR></DIV><DIV>--<BR>Thomas Annen,<BR>Computer Graphics Group - AG4<BR=
>Max-Planck-Institut Informatik<BR>Stuhlsatzenhausweg 85, 66123 Saarbr=C3=
=BCcken, Germany<BR>Phone: +49 681 9325-426 Fax: +49 681 9325-499<BR><A hre=
f=3D"mailto:ta...@mp..." target=3Dblank >ta...@mp...</A><=
BR></DIV></FONT>=

[Chromium-dev] code clean-up in opengl_stub/

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

The stubCreateContext() routine in context.c was a bunch of #ifdef'd 
code.  I've moved the body of that function into each of the glx.c, 
wgl.c and cgl.c files and removed the unneeded #ifdef clauses.

I don't think I broke the wgl or cgl code.  But if I did, let me know. 
  I'm sure the fixes will be trivial.

-Brian

[Chromium-dev] Re: Pixel-image compression within Chromium?

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

Do you suspect it's texture images that are the source of the problem? 
  Or glDrawPixels?  You mentioned images in your post.

Textures are typically specified in GL_RGB or GL_RGBA format with 
GLubytes.  Since those are byte-sized components, there shouldn't be 
any endian issues.

If you see the problem with any small, simple GL demos (like the 
redbook or GLUT demos) that would help narrow it down.  Even a screen 
shot showing the problem could give us a clue.

Chromium doesn't normally do any image compression.

-Brian


aac...@ad... wrote:
> Hello,
> 
> I posted something about this problem before, but have not gotten any response.  To re-iterate, certain colors on certain applications run through Chromium from a Windows Box (mothership and crappfaker) to a crserver running with OMP (like DMX) on an SGI Onyx 4 running IRIX do not appear correctly.   
> 
> One problem is that the Chromium Print-SPU doesn't include data in its output; only the address of the texture image in memory, so I can't see the data that the application's sending to Chromium.
> 
> For those of you who know the inner workings of Chromium, is it possible that Chromium is doing some kind of pixel-image compression, and there are bit errors being introduced because of that?  If it does do pixel-image compression, is it possible to turn this compression off??
> 
> Thanks for your help,
> Alicia
> 
> 
> 
> 
> 
> 
>>From:  <aac...@ad...>
>>To: chr...@li...
>>Subject: [Chromium-dev] disparate colors using Windows->Onyx4
>>Date: Fri, 10 Dec 2004 15:58:49 -0800
>>
>>Hello Chromium community,
>>
> 
>   
> 
> We are setting up Chromium to run (mothership and crappfaker) on a Windows box and the crserver on an SGI Onyx 4 with IRIX.  
> 
> 
> When running some applications, the colors that show-up on the Onyx 4 rendering nodes have disparate colors and apparent dithering.  Many OpenGL programs such as Atlantis, City, etc, do not have any color variations at all.  BUT, some important in-house applications and other third-party applications do not show the color-schemes one would expect.  Oceans that normally appear blue on a globe, might look purple, etc when passed through Chromium and displayed on the Onyx 4 crserver.  
> 
> 
> Not all colors are off, but noticeably some are.      
> 
>  
> 
> I was wondering if anyone has seen this effect before?  I know I'd seen displays show all-white when textures could not be rendered due to video-card problems, but I haven't seen color-abnormalities like are appearing now. 
> 
>  
> 
> The video cards on the 2x2 SGI display are not all the same.  Two of the video cards are Firegl GL X2 and two of the other video cards are Firegl GL X1.  The Windows box also has a Firegl GL X1.  
> 
>  
> 
> Some of the ideas to fix this problem have been:
> 
> 
> Big-endian, Little-endian...perhaps going between Windows to Onyx results in some kind of color-transformation via the Big-endian, Little-endian of the color values?
> 
> 
> We bought an identical Video card for the Windows machine, in the hopes that that would ensure identical color-map for both the Onyx and Windows machines.  Apparently that was not the issue either, as everything still has the same color difficulties.
> 
> 
> Does the Windows box have one color-map, and the Onyx a different color map that is being referenced that would cause these problems?
> 
> 
> Let me know if you have any ideas.
> 
>  
> 
> Thanks so much for your help,
> 
> Alicia 
> 
>  
> 
> 
> 
> 
> -------------------------------------------------------
> 
> SF email is sponsored by - The IT Product Guide
> 
> Read honest & candid reviews on hundreds of IT Products from real users.
> 
> Discover which products truly live up to the hype. Start reading now. 
> 
> http://productguide.itmanagersjournal.com/
> 
> _______________________________________________
> 
> Chromium-dev mailing list
> 
> Chr...@li...
> 
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> 
> 

[Chromium-dev] Pixel-image compression within Chromium?

[<aac...@ad...>]

Hello,

I posted something about this problem before, but have not gotten any response.  To re-iterate, certain colors on certain applications run through Chromium from a Windows Box (mothership and crappfaker) to a crserver running with OMP (like DMX) on an SGI Onyx 4 running IRIX do not appear correctly.   

One problem is that the Chromium Print-SPU doesn't include data in its output; only the address of the texture image in memory, so I can't see the data that the application's sending to Chromium.

For those of you who know the inner workings of Chromium, is it possible that Chromium is doing some kind of pixel-image compression, and there are bit errors being introduced because of that?  If it does do pixel-image compression, is it possible to turn this compression off??

Thanks for your help,
Alicia





> From:  <aac...@ad...>
> To: chr...@li...
> Subject: [Chromium-dev] disparate colors using Windows->Onyx4
> Date: Fri, 10 Dec 2004 15:58:49 -0800
> 
> Hello Chromium community,
> 
  
> 
We are setting up Chromium to run (mothership and crappfaker) on a Windows box and the crserver on an SGI Onyx 4 with IRIX.  
> 

> 
When running some applications, the colors that show-up on the Onyx 4 rendering nodes have disparate colors and apparent dithering.  Many OpenGL programs such as Atlantis, City, etc, do not have any color variations at all.  BUT, some important in-house applications and other third-party applications do not show the color-schemes one would expect.  Oceans that normally appear blue on a globe, might look purple, etc when passed through Chromium and displayed on the Onyx 4 crserver.  
> 

> 
Not all colors are off, but noticeably some are.      
> 
 
> 
I was wondering if anyone has seen this effect before?  I know I'd seen displays show all-white when textures could not be rendered due to video-card problems, but I haven't seen color-abnormalities like are appearing now. 
> 
 
> 
The video cards on the 2x2 SGI display are not all the same.  Two of the video cards are Firegl GL X2 and two of the other video cards are Firegl GL X1.  The Windows box also has a Firegl GL X1.  
> 
 
> 
Some of the ideas to fix this problem have been:
> 

> 
Big-endian, Little-endian...perhaps going between Windows to Onyx results in some kind of color-transformation via the Big-endian, Little-endian of the color values?
> 

> 
We bought an identical Video card for the Windows machine, in the hopes that that would ensure identical color-map for both the Onyx and Windows machines.  Apparently that was not the issue either, as everything still has the same color difficulties.
> 

> 
Does the Windows box have one color-map, and the Onyx a different color map that is being referenced that would cause these problems?
> 

> 
Let me know if you have any ideas.
> 
 
> 
Thanks so much for your help,
> 
Alicia 
> 
 
> 

> 

> 

> 
-------------------------------------------------------
> 
SF email is sponsored by - The IT Product Guide
> 
Read honest & candid reviews on hundreds of IT Products from real users.
> 
Discover which products truly live up to the hype. Start reading now. 
> 
http://productguide.itmanagersjournal.com/
> 
_______________________________________________
> 
Chromium-dev mailing list
> 
Chr...@li...
> 
https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 

Re: [Chromium-dev] glGenPrograms segfault

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

Reinstalling the 3.14.6 drivers seem to fix things up.  With a minor 
change to Raptor, it is now working again as well.  Now back to the 
window resize issues.

-Mike

Mike Houston wrote:

> Oh goodie.  It looks like another odd intereaction between Chromium 
> and the ATI drivers I have.
>
> -Mike
>
> Brian Paul wrote:
>
>> Mike Houston wrote:
>>
>>> Arbfraglight works happily locally running with the conf file listed 
>>> at the bottom, but completely borks when the appfaker is run 
>>> remotely.  The bug can be demonstrated with arbfraglight.
>>>
>>> There seems to be something funky with extension loading on remote 
>>> nodes.  In particular, glGenProgramsARB is failing.  crGetProcAdress 
>>> as well as the wgl/glx version returns an address successfully, but 
>>> actually calling the function causes a segfault or occasionally an 
>>> abort (SIGABRT).  I've tried multiple ATI driver revisions including 
>>> ones known to work with previous Chromium releases.  Somewhere, we 
>>> must be stepping on memory or getting a bogus entry in the function 
>>> table.
>>>
>>> Can someone with Nvidia systems see if they can reproduce the bug?
>>
>>
>>
>> Seems to work fine with my NVIDIA Quadro card.
>>
>> -Brian
>>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] glGenPrograms segfault

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

Oh goodie.  It looks like another odd intereaction between Chromium and 
the ATI drivers I have.

-Mike

Brian Paul wrote:

> Mike Houston wrote:
>
>> Arbfraglight works happily locally running with the conf file listed 
>> at the bottom, but completely borks when the appfaker is run 
>> remotely.  The bug can be demonstrated with arbfraglight.
>>
>> There seems to be something funky with extension loading on remote 
>> nodes.  In particular, glGenProgramsARB is failing.  crGetProcAdress 
>> as well as the wgl/glx version returns an address successfully, but 
>> actually calling the function causes a segfault or occasionally an 
>> abort (SIGABRT).  I've tried multiple ATI driver revisions including 
>> ones known to work with previous Chromium releases.  Somewhere, we 
>> must be stepping on memory or getting a bogus entry in the function 
>> table.
>>
>> Can someone with Nvidia systems see if they can reproduce the bug?
>
>
> Seems to work fine with my NVIDIA Quadro card.
>
> -Brian
>

Re: [Chromium-dev] glGenPrograms segfault

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

Mike Houston wrote:
> Arbfraglight works happily locally running with the conf file listed at 
> the bottom, but completely borks when the appfaker is run remotely.  The 
> bug can be demonstrated with arbfraglight.
> 
> There seems to be something funky with extension loading on remote 
> nodes.  In particular, glGenProgramsARB is failing.  crGetProcAdress as 
> well as the wgl/glx version returns an address successfully, but 
> actually calling the function causes a segfault or occasionally an abort 
> (SIGABRT).  I've tried multiple ATI driver revisions including ones 
> known to work with previous Chromium releases.  Somewhere, we must be 
> stepping on memory or getting a bogus entry in the function table.
> 
> Can someone with Nvidia systems see if they can reproduce the bug?

Seems to work fine with my NVIDIA Quadro card.

-Brian

[Chromium-dev] glGenPrograms segfault

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

Arbfraglight works happily locally running with the conf file listed at 
the bottom, but completely borks when the appfaker is run remotely.  The 
bug can be demonstrated with arbfraglight.

There seems to be something funky with extension loading on remote 
nodes.  In particular, glGenProgramsARB is failing.  crGetProcAdress as 
well as the wgl/glx version returns an address successfully, but 
actually calling the function causes a segfault or occasionally an abort 
(SIGABRT).  I've tried multiple ATI driver revisions including ones 
known to work with previous Chromium releases.  Somewhere, we must be 
stepping on memory or getting a bogus entry in the function table.

Can someone with Nvidia systems see if they can reproduce the bug?

Thanks!
-Mike

import sys
sys.path.append( "../server" )
from mothership import *

Demo = 'arbfraglight'

Demo = os.path.join(crbindir, Demo)

mothershipPort = 10000
localHostname = os.uname()[1]

# Set up the server node
servernode1 = CRNetworkNode( )
# Note: each client has the -swap flag and we tell the server to only
# do one SwapBuffers here.
servernode1.Conf( 'only_swap_once', 1 )
servernode1.Conf( 'shared_windows', 1 )
renderspu = SPU( 'render' )
renderspu.Conf( 'window_geometry', [500, 500, 400, 400] )
servernode1.AddSPU( renderspu )

# Set up first app/client node
appnode1 = CRApplicationNode(  )
appnode1.SetApplication( '%s' % (Demo) )
appnode1.StartDir( crbindir )
spu = SPU('readback')
spu.Conf('window_geometry', [0, 0, 400, 400])
appnode1.AddSPU( spu )
spu = SPU('pack')
appnode1.AddSPU( spu )
spu.AddServer( servernode1, 'tcpip' )

cr = CR()
cr.MTU( 1024*1024 )
# Note: adding nodes in the order in which they must be started!
cr.AddNode( appnode1 )
cr.AddNode( servernode1 )
cr.Go()

Re: [Chromium-dev] More CRUT breakage

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

Ignoring the window resize problem for now, I seem to be having problems 
with glGenPrograms, but only when running applications are running 
remote with the readback SPU.  When running locally, everything is 
happy, but moving to running the application remotely causes a segfault 
when calling glGenPrograms.  Has anyone seen this behavior recently?  
I'm going to try to get a simple test case with arbfraglight misbehaving.

-Mike

Brian Paul wrote:

>
> OK, Looking at the code, glParametervCR(GL_WINDOW_SIZE_CR, GL_INT, 2, 
> winsize) will only work for resizing the default window.  Note that 
> the crHashtableSearch() call's last parameter is zero.  Yet another 
> example of the old default window/context cruft.
>
> You should probably use crWindowSize(windowID, width, height) instead.
>
> Where are you making that call?  Do you have a Chromium window ID at 
> that point?
>
> -Brian
>
>
> Mike Houston wrote:
>
>> Hrmm.  Calling glParametervCR(GL_WINDOW_SIZE_CR, GL_INT, 2, winsize) 
>> seems to have no effect anymore on the render/readback spu.
>>
>> -Mike
>>
>> Mike Houston wrote:
>>
>>> psubmit_crut might be a bad example since we should probably handle 
>>> reshape via CRUT/GLUT...  Still trying to track why Raptor is broken.
>>>
>>> -Mike
>>>
>>> Mike Houston wrote:
>>>
>>>> Window resizing is no longer working correctly.  Try crut_fan.conf 
>>>> with resizable set to 1.  It seems that the changes to 
>>>> render/readback have slightly borked CRUT, or at least the some of 
>>>> the feedback paths.  Raptor now no longer runs correctly, so I'm 
>>>> starting with the simple cases first.
>>>>
>>>> -Mike
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> The SF.Net email is sponsored by: Beat the post-holiday blues
>>>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>>>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>>>> _______________________________________________
>>>> Chromium-dev mailing list
>>>> Chr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Chromium-dev mailing list
> Chr...@li...
> https://lists.sourceforge.net/lists/listinfo/chromium-dev

Re: [Chromium-dev] More CRUT breakage

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

CrWindowSize is a new call since the 1.6 CR release Raptor and the CRUT 
examples were written against.  glParam should do the right thing.  I 
guess this is a question of what the right way to do this for a remote 
Chromium app. 

crutWindowCreate is NOT quite doing the right thing.  I get the 
renderspu window AND the crut window, i.e run crut_fan.conf and you'll 
get 5 total windows (1 crutserver, 2 app windows, and 2 render 
windows).  If I enable render_to_app _window, bad bad things happen if 
everything is run on the local host.  Everything renders into the 
crut_window.

Now I have a strange situation where things work great now on the local 
host, but magically segfaults or SIGABRT (!), when run remote.  I'll try 
to dig this out tomorrow.

-Mike

Brian Paul wrote:

>
> OK, Looking at the code, glParametervCR(GL_WINDOW_SIZE_CR, GL_INT, 2, 
> winsize) will only work for resizing the default window.  Note that 
> the crHashtableSearch() call's last parameter is zero.  Yet another 
> example of the old default window/context cruft.
>
> You should probably use crWindowSize(windowID, width, height) instead.
>
> Where are you making that call?  Do you have a Chromium window ID at 
> that point?
>
> -Brian
>
>
> Mike Houston wrote:
>
>> Hrmm.  Calling glParametervCR(GL_WINDOW_SIZE_CR, GL_INT, 2, winsize) 
>> seems to have no effect anymore on the render/readback spu.
>>
>> -Mike
>>
>> Mike Houston wrote:
>>
>>> psubmit_crut might be a bad example since we should probably handle 
>>> reshape via CRUT/GLUT...  Still trying to track why Raptor is broken.
>>>
>>> -Mike
>>>
>>> Mike Houston wrote:
>>>
>>>> Window resizing is no longer working correctly.  Try crut_fan.conf 
>>>> with resizable set to 1.  It seems that the changes to 
>>>> render/readback have slightly borked CRUT, or at least the some of 
>>>> the feedback paths.  Raptor now no longer runs correctly, so I'm 
>>>> starting with the simple cases first.
>>>>
>>>> -Mike
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> The SF.Net email is sponsored by: Beat the post-holiday blues
>>>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>>>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>>>> _______________________________________________
>>>> Chromium-dev mailing list
>>>> Chr...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> The SF.Net email is sponsored by: Beat the post-holiday blues
>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>> _______________________________________________
>> Chromium-dev mailing list
>> Chr...@li...
>> https://lists.sourceforge.net/lists/listinfo/chromium-dev
>>
>