Menu
▾
▴
chromium-users — Mailing list for all users of the Chromuim rendering system
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(5) |
Aug
(20) |
Sep
(12) |
Oct
(1) |
Nov
(5) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
(13) |
Mar
(14) |
Apr
(33) |
May
(15) |
Jun
(49) |
Jul
(24) |
Aug
(90) |
Sep
(13) |
Oct
(85) |
Nov
(25) |
Dec
(6) |
| 2003 |
Jan
(9) |
Feb
(89) |
Mar
(85) |
Apr
(98) |
May
(30) |
Jun
(55) |
Jul
(79) |
Aug
(78) |
Sep
(77) |
Oct
(47) |
Nov
(48) |
Dec
(18) |
| 2004 |
Jan
(75) |
Feb
(176) |
Mar
(137) |
Apr
(67) |
May
(119) |
Jun
(128) |
Jul
(53) |
Aug
(50) |
Sep
(46) |
Oct
(55) |
Nov
(53) |
Dec
(25) |
| 2005 |
Jan
(34) |
Feb
(21) |
Mar
(29) |
Apr
(48) |
May
(23) |
Jun
(35) |
Jul
(18) |
Aug
(69) |
Sep
(49) |
Oct
(35) |
Nov
(16) |
Dec
(7) |
| 2006 |
Jan
(21) |
Feb
(17) |
Mar
(16) |
Apr
(20) |
May
(48) |
Jun
(19) |
Jul
(23) |
Aug
(55) |
Sep
(42) |
Oct
(7) |
Nov
(7) |
Dec
(4) |
| 2007 |
Jan
(6) |
Feb
(17) |
Mar
(3) |
Apr
(6) |
May
(4) |
Jun
(12) |
Jul
(1) |
Aug
(7) |
Sep
(11) |
Oct
(1) |
Nov
(10) |
Dec
(4) |
| 2008 |
Jan
(5) |
Feb
(7) |
Mar
(12) |
Apr
(21) |
May
(1) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(4) |
Nov
(7) |
Dec
(9) |
| 2009 |
Jan
(4) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(10) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2010 |
Jan
(4) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Brian P. <bri...@tu...> - 2006-08-07 14:14:51
|
James Supancic wrote:
> While you got Sauerbraten running, you broke tuxracer. I was looking
> that the cvs diff to see what you did, and I noticed this
> case GL_UNSIGNED_SHORT:
> {
> const GLushort *p = (const GLushort *) indices;
> for (i=0; i<count; i++)
> crPackExpandArrayElement(p[i], c);
> }
> break;
> case GL_UNSIGNED_INT:
> {
> const GLushort *p = (const GLushort *) indices;
> for (i = 0; i < count; i++)
> crPackExpandArrayElement(p[i], c);
> }
> I find that replacing const GLushort *p = (const GLushort *) indices;
> with const GLuint *p = (const GLuint *) indices; for case
> GL_UNSIGNED_INT will fix tuxracer (which is a mission critical
> application for many people).
OK, fixed.
-Brian
|
|
From: James S. <arr...@gm...> - 2006-08-07 11:17:05
|
Tilesort generates needed network traffic?
I have four Render SPUs and one Tilesort SPU. I have noticed that some
applications run slowly when they are rendering only to the local Render SPU
(ig. application, tilesort and render SPU are all on one host) while at the
same time using little CPU time. I replaced the 3 Render SPUs on remote
hosts with NOP SPUs on the localhost and found that CPU consumption went up
to 100% and applications ran faster. Suspecting that something about the
remote Render SPUs might be slowing down local rendering I inserted a Print
SPU on one of the remote nodes (note that the applications window is only on
the local X server, none of the remote X server/Render SPUs should be used).
I ran the atlantis text program and got this output:
LoadIdentity( )
MatrixMode( GL_PROJECTION )
LoadMatrixf( [ 1.37 0.00 0.00 0.00
0.00 2.75 0.00 0.00
0.00 0.00 -1.05 -1.00
0.00 0.00 -20512.82 0.00 ] )
MatrixMode( GL_MODELVIEW )
MatrixMode( GL_MODELVIEW )
PushMatrix( )
LoadIdentity( )
PopMatrix( )
MatrixMode( GL_MODELVIEW )
Clear( 0x4100 )
LoadIdentity( )
SwapBuffers( 1, 0 )
MakeCurrent( 1, 0, 1 )
LoadIdentity( )
MatrixMode( GL_PROJECTION )
LoadMatrixf( [ 1.37 0.00 0.00 0.00
0.00 2.75 0.00 0.00
0.00 0.00 -1.05 -1.00
0.00 0.00 -20512.82 0.00 ] )
MatrixMode( GL_MODELVIEW )
MatrixMode( GL_MODELVIEW )
PushMatrix( )
LoadIdentity( )
PopMatrix( )
MatrixMode( GL_MODELVIEW )
Clear( 0x4100 )
LoadIdentity( )
SwapBuffers( 1, 0 )
MakeCurrent( 1, 0, 1 )
LoadIdentity( )
MatrixMode( GL_PROJECTION )
LoadMatrixf( [ 1.37 0.00 0.00 0.00
0.00 2.75 0.00 0.00
0.00 0.00 -1.05 -1.00
0.00 0.00 -20512.82 0.00 ] )
MatrixMode( GL_MODELVIEW )
MatrixMode( GL_MODELVIEW )
PushMatrix( )
LoadIdentity( )
PopMatrix( )
MatrixMode( GL_MODELVIEW )
Clear( 0x4100 )
LoadIdentity( )
SwapBuffers( 1, 0 )
MakeCurrent( 1, 0, 1 )
LoadIdentity( )
MatrixMode( GL_PROJECTION )
LoadMatrixf( [ 1.37 0.00 0.00 0.00
0.00 2.75 0.00 0.00
0.00 0.00 -1.05 -1.00
0.00 0.00 -20512.82 0.00 ] )
MatrixMode( GL_MODELVIEW )
MatrixMode( GL_MODELVIEW )
PushMatrix( )
LoadIdentity( )
PopMatrix( )
The Tilesort SPU is clearly sending data to the remote Render SPUs. Why? I
am using the Test All Tiles bucket mode, I am using auto_dlist_bbox,
lazy_send_dlists, and dlist_state_tracking. Why is this data being sent? How
can I eliminate it?
Thank you for your time,
James Steven Supancic III
|
|
From: James S. <arr...@gm...> - 2006-08-05 08:46:59
|
While you got Sauerbraten running, you broke tuxracer. I was looking that
the cvs diff to see what you did, and I noticed this
case GL_UNSIGNED_SHORT:
{
const GLushort *p = (const GLushort *) indices;
for (i=0; i<count; i++)
crPackExpandArrayElement(p[i], c);
}
break;
case GL_UNSIGNED_INT:
{
const GLushort *p = (const GLushort *) indices;
for (i = 0; i < count; i++)
crPackExpandArrayElement(p[i], c);
}
I find that replacing const GLushort *p = (const GLushort *) indices; with
const GLuint *p = (const GLuint *) indices; for case GL_UNSIGNED_INT will
fix tuxracer (which is a mission critical application for many people).
Thank you for your time,
James Steven Supancic III
On 8/4/06, James Supancic <arr...@gm...> wrote:
>
> The application is still very slow, but it no longer causes segmentation
> faults =) I am going to toy with some configuration options and see if I can
> speed it up a bit that way.
>
> Thank you very much.
>
>
> Thank you for your time,
> James Steven Supancic III
>
> On 8/4/06, Brian Paul <bri...@tu...> wrote:
> >
> > James Supancic wrote:
> > > I think you may have left the deffintion of
> > > crStateUseServerArrayElements out. I did a cvs checkout to be sure, I
> > > tried to build, it failed. so I did
> > > grep -ri crStateUseServerArrayElements ./*
> > > and it returns one line
> > > ./spu/tilesort/tilesortspu_client.c:
> > > crStateUseServerArrayElements()) {
> > >
> >
> > Sorry, I forgot to check in a couple files. Try again.
> >
> > -Brian
> >
>
>
|
|
From: James S. <arr...@gm...> - 2006-08-05 03:20:20
|
The application is still very slow, but it no longer causes segmentation
faults =) I am going to toy with some configuration options and see if I can
speed it up a bit that way.
Thank you very much.
Thank you for your time,
James Steven Supancic III
On 8/4/06, Brian Paul <bri...@tu...> wrote:
>
> James Supancic wrote:
> > I think you may have left the deffintion of
> > crStateUseServerArrayElements out. I did a cvs checkout to be sure, I
> > tried to build, it failed. so I did
> > grep -ri crStateUseServerArrayElements ./*
> > and it returns one line
> > ./spu/tilesort/tilesortspu_client.c:
> > crStateUseServerArrayElements()) {
> >
>
> Sorry, I forgot to check in a couple files. Try again.
>
> -Brian
>
|
|
From: Brian P. <bri...@tu...> - 2006-08-04 13:38:05
|
James Supancic wrote:
> I think you may have left the deffintion of
> crStateUseServerArrayElements out. I did a cvs checkout to be sure, I
> tried to build, it failed. so I did
> grep -ri crStateUseServerArrayElements ./*
> and it returns one line
> ./spu/tilesort/tilesortspu_client.c:
> crStateUseServerArrayElements()) {
>
Sorry, I forgot to check in a couple files. Try again.
-Brian
|
|
From: James S. <arr...@gm...> - 2006-08-04 07:08:45
|
I think you may have left the deffintion of crStateUseServerArrayElements
out. I did a cvs checkout to be sure, I tried to build, it failed. so I did
grep -ri crStateUseServerArrayElements ./*
and it returns one line
./spu/tilesort/tilesortspu_client.c:
crStateUseServerArrayElements()) {
ig, you are calling a function without a deffintion. I think...
the tail of the build error is
Compiling tilesortspu_client.c
tilesortspu_client.c: In function `tilesortspu_DrawElements':
tilesortspu_client.c:134: warning: implicit declaration of function
`crStateUseServerArrayElements'
gmake[3]: *** [../../built/tilesortspu/Linux/tilesortspu_client.o] Error 1
gmake[2]: *** [dep] Error 2
gmake[1]: *** [tilesort.subdir] Error 2
make: *** [spu.subdir] Error 2
Thank you for your time,
James Steven Supancic III
On 8/3/06, Brian Paul <bri...@tu...> wrote:
>
>
> Ok, I think I've fixed the vertex array / VBO problem.
>
> We were crashing in glDrawElements() when the vertex data was in a
> server-side VBO but the array element indices were local.
>
> Sauerbraten is a little sub-optimal in that regard. If you're going
> to put your vertex data into a VBO and you're going to use
> glDrawElements(), the element indices should go in a
> GL_ELEMENT_ARRAY_BUFFER buffer to get best performance.
>
> -Brian
>
>
|
|
From: Brian P. <bri...@tu...> - 2006-08-03 20:37:03
|
Ok, I think I've fixed the vertex array / VBO problem. We were crashing in glDrawElements() when the vertex data was in a server-side VBO but the array element indices were local. Sauerbraten is a little sub-optimal in that regard. If you're going to put your vertex data into a VBO and you're going to use glDrawElements(), the element indices should go in a GL_ELEMENT_ARRAY_BUFFER buffer to get best performance. -Brian |
|
From: James S. <arr...@gm...> - 2006-08-02 21:42:38
|
Sauerbraten is a free (open source) fps released under the ZLIB license. It is something of a clone of Quake. http://sauerbraten.org/ is the project page. http://sourceforge.net/project/showfiles.php?group_id=102911 is the source forge download page. sauerbraten_2006_07_22_normalmap_edition_linux.tar.gz<http://prdownloads.sourceforge.net/sauerbraten/sauerbraten_2006_07_22_normalmap_edition_linux.tar.gz?download>contains both the source code and pre-compiled binaries. Thank you for your time, James Steven Supancic III On 8/2/06, Brian Paul <bri...@tu...> wrote: > > James Supancic wrote: > > I updated my local copy of the source code (with cvs up) and rebuilt. > > bufferobj now runs properly. However, Sauerbraten still causes the > > crservers to segfault (with the same error). > > > > What did you have to change to fix bufferobj? > > The state differencer was using diff_api.GetString() to determine if > the GL_ARB_vertex_buffer_object extension was available. In the > tilesort SPU, that function pointer was NULL, so the state differencer > wasn't sending the VBO data to the crservers. > > What is Sauerbraten and where can I get it to test? > > -Brian > > |
|
From: Brian P. <bri...@tu...> - 2006-08-02 14:30:21
|
James Supancic wrote: > I updated my local copy of the source code (with cvs up) and rebuilt. > bufferobj now runs properly. However, Sauerbraten still causes the > crservers to segfault (with the same error). > > What did you have to change to fix bufferobj? The state differencer was using diff_api.GetString() to determine if the GL_ARB_vertex_buffer_object extension was available. In the tilesort SPU, that function pointer was NULL, so the state differencer wasn't sending the VBO data to the crservers. What is Sauerbraten and where can I get it to test? -Brian |
|
From: James S. <arr...@gm...> - 2006-08-01 20:45:52
|
I updated my local copy of the source code (with cvs up) and rebuilt. bufferobj now runs properly. However, Sauerbraten still causes the crservers to segfault (with the same error). What did you have to change to fix bufferobj? When I run Sauerbraten I get: Render SPU 1: SegFault [0xffffe420] Render SPU 2: SegFault /lib/libpthread.so.0[0xb7ae8e87] [0xffffe420] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb739187b] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb7390e49] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb7390e49] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x5c)[0xb7e2f9f0] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7e2ef3c] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7e2b643] /opt/cr/bin/Linux/crserver[0x805657e] /opt/cr/bin/Linux/crserver[0x805669f] /opt/cr/bin/Linux/crserver[0x8056789] /opt/cr/bin/Linux/crserver[0x80567c7] /opt/cr/bin/Linux/crserver[0x804a537] /opt/cr/bin/Linux/crserver[0x804a092] /lib/libc.so.6(__libc_start_main+0xa6)[0xb7c153a6] /opt/cr/bin/Linux/crserver[0x8049fd1] Render SPU 3: Segfault /lib/libpthread.so.0[0xb7adef37] [0xffffe420] Render SPU 4: Segfault /lib/libpthread.so.0[0xb7acfe87] [0xffffe420] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb737887b] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb7377e49] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb7377e49] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x5c)[0xb7e169f0] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7e15f3c] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7e12643] /opt/cr/bin/Linux/crserver[0x805657e] /opt/cr/bin/Linux/crserver[0x805669f] /opt/cr/bin/Linux/crserver[0x8056789] /opt/cr/bin/Linux/crserver[0x80567c7] /opt/cr/bin/Linux/crserver[0x804a537] /opt/cr/bin/Linux/crserver[0x804a092] /lib/libc.so.6(__libc_start_main+0xa6)[0xb7bfc3a6] /opt/cr/bin/Linux/crserver[0x8049fd1] Thank you for your time, James Steven Supancic III On 8/1/06, Brian Paul <bri...@tu... > wrote: > > James Supancic wrote: > > I compiled and ran bufferobj.c, the results: > > > > Render SPU 1: Segfault > [...] > > > > Are you able to run it without issue? What kind of configuration did you > > use? > > It was broken here too. I've just checked in the fix to the tilesort > SPU code. Can you try the CVS code? Otherwise, I could send you a patch. > > -Brian > |
|
From: Brian P. <bri...@tu...> - 2006-08-01 17:53:53
|
James Supancic wrote: > I compiled and ran bufferobj.c, the results: > > Render SPU 1: Segfault [...] > > Are you able to run it without issue? What kind of configuration did you > use? It was broken here too. I've just checked in the fix to the tilesort SPU code. Can you try the CVS code? Otherwise, I could send you a patch. -Brian |
|
From: James S. <arr...@gm...> - 2006-08-01 02:28:51
|
I compiled and ran bufferobj.c, the results: Render SPU 1: Segfault /lib/libpthread.so.0[0xb7aedf37] [0xffffe420] /usr/lib/libGLcore.so.1[0xb757d9c2] Render SPU 2: Segfault /usr/lib/opengl/nvidia/lib/libGLcore.so.1[0xb75a7c22] Render SPU 3: Segfault: /lib/libpthread.so.0[0xb7a98e87] [0xffffe420] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__R300TCLProcessArrayPrimitive+0x183)[0xb733af53] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawArrays+0xff)[0xb734291f] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7dd8aa7] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x218)[0xb7ddaebe] /opt/cr/bin/Linux/crserver[0x805657e] /opt/cr/bin/Linux/crserver[0x805669f] /opt/cr/bin/Linux/crserver[0x8056789] /opt/cr/bin/Linux/crserver[0x80567c7] /opt/cr/bin/Linux/crserver[0x804a537] /opt/cr/bin/Linux/crserver[0x804a092] /lib/libc.so.6(__libc_start_main+0xa6)[0xb7bc53a6] /opt/cr/bin/Linux/crserver[0x8049fd1] Render SPU 4: Segfault /lib/libpthread.so.0[0xb7acee87] [0xffffe420] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__R300TCLProcessArrayPrimitive+0x183)[0xb7370f53] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawArrays+0xff)[0xb737891f] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7e0eaa7] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x218)[0xb7e10ebe] /opt/cr/bin/Linux/crserver[0x805657e] /opt/cr/bin/Linux/crserver[0x805669f] /opt/cr/bin/Linux/crserver[0x8056789] /opt/cr/bin/Linux/crserver[0x80567c7] /opt/cr/bin/Linux/crserver[0x804a537] /opt/cr/bin/Linux/crserver[0x804a092] /lib/libc.so.6(__libc_start_main+0xa6)[0xb7bfb3a6] /opt/cr/bin/Linux/crserver[0x8049fd1] Are you able to run it without issue? What kind of configuration did you use? Thank you for your time, James Steven Supancic III On 7/31/06, Brian Paul <bri...@tu...> wrote: > > If possible, could you try out the Mesa bufferobj.c demo? It's the > program I used to test VBOs with the tilesort SPU. > > You can get it here: > > http://webcvs.freedesktop.org/mesa/Mesa/progs/tests/bufferobj.c?content-type=text%2Fplain&view=co > > -Brian > > James Supancic wrote: > > yes, My application uses glGetString(GL_EXTENSIONS); and strstr to tell > > if the OpenGL implementation supports GL_ARB_vertex_buffer_object. It > > uses the extension to speed up rendering of geometry heavy scenes. > > > > I think Chromium should either 1) Not segfualt when the extension is > > used or 2) Not tell the application that it is supported, though, I > > prefer the first option myself. > > > > I am using a basic autodmx config, I changed the basic config a bit to > > get it to use ssh rather than rsh for starting the crservers, but that > > is about it. > > > > Basically, I have a single tilesort SPU and a render SPU on each of the > > four backends. > > > > Thank you for your time, > > James Steven Supancic III > > > > On 7/31/06, *Brian Paul* <bri...@tu... > > <mailto:bri...@tu...>> wrote: > > > > James Supancic wrote: > > > segmentation fault in crserver. > > > > > > I am attempting to run Sauerbraten using Chromium. I have two > > nVidia and > > > two ATI render SPUs. > > > All four render SPUs crash, I was able to get the following stack > > trace > > > from the ATI SPUs. > > > /lib/libpthread.so.0[0xb7ab5e87] > > > [0xffffe420] > > > > > > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb735e87b] > > > > > > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] > > > > > > > > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] > > > > > > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x7b)[0xb7dfca5f] > > > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7dfbf8c] > > > > > > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7df8693] > > > /opt/cr/bin/Linux/crserver[0x805657e] > > > /opt/cr/bin/Linux/crserver[0x805669f] > > > /opt/cr/bin/Linux/crserver[0x8056789] > > > /opt/cr/bin/Linux/crserver[0x80567c7] > > > /opt/cr/bin/Linux/crserver[0x804a537] > > > /opt/cr/bin/Linux/crserver[0x804a092] > > > /lib/libc.so.6(__libc_start_main+0xa6)[0xb7be23a6] > > > /opt/cr/bin/Linux/crserver[0x8049fd1] > > > > > > The stacktrace from the nVidia SPUs is much less interesting: > > > /lib/libpthread.so.0[0xb7afcf37] > > > [0xffffe420] > > > > > > I have noticed that by commenting out > > > cr_unpackDispatch.DrawElements( mode, count, type, (void *) > > indices); > > > in the function crUnpackExtendedDrawElements in the file > > unpack_arrays.c > > > and rebuilding Chromium I am able to eliminate the segfaults (the > > > application still doesn't work, I get some output, but other > > things are > > > missing). Using gdb I was able to determine that none of my other > > > applications cause the crUnpackExtendedDrawElements function to > > be called. > > > > > > Is something wrong with crUnpackExtendedDrawElements? > > > > crUnpackExtendedDrawElements() should only be getting used if you're > > using server-side vertex arrays via the GL_ARB_vertex_buffer_object > > extension. Are you? > > > > Otherwise, we're probably packing/sending DrawElements() by mistake. > > What kind of config file are you using? Tilesort? > > > > -Brian > > > > > > |
|
From: Brian P. <bri...@tu...> - 2006-07-31 21:46:22
|
If possible, could you try out the Mesa bufferobj.c demo? It's the program I used to test VBOs with the tilesort SPU. You can get it here: http://webcvs.freedesktop.org/mesa/Mesa/progs/tests/bufferobj.c?content-type=text%2Fplain&view=co -Brian James Supancic wrote: > yes, My application uses glGetString(GL_EXTENSIONS); and strstr to tell > if the OpenGL implementation supports GL_ARB_vertex_buffer_object. It > uses the extension to speed up rendering of geometry heavy scenes. > > I think Chromium should either 1) Not segfualt when the extension is > used or 2) Not tell the application that it is supported, though, I > prefer the first option myself. > > I am using a basic autodmx config, I changed the basic config a bit to > get it to use ssh rather than rsh for starting the crservers, but that > is about it. > > Basically, I have a single tilesort SPU and a render SPU on each of the > four backends. > > Thank you for your time, > James Steven Supancic III > > On 7/31/06, *Brian Paul* <bri...@tu... > <mailto:bri...@tu...>> wrote: > > James Supancic wrote: > > segmentation fault in crserver. > > > > I am attempting to run Sauerbraten using Chromium. I have two > nVidia and > > two ATI render SPUs. > > All four render SPUs crash, I was able to get the following stack > trace > > from the ATI SPUs. > > /lib/libpthread.so.0[0xb7ab5e87] > > [0xffffe420] > > > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb735e87b] > > > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] > > > > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] > > > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x7b)[0xb7dfca5f] > > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7dfbf8c] > > > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7df8693] > > /opt/cr/bin/Linux/crserver[0x805657e] > > /opt/cr/bin/Linux/crserver[0x805669f] > > /opt/cr/bin/Linux/crserver[0x8056789] > > /opt/cr/bin/Linux/crserver[0x80567c7] > > /opt/cr/bin/Linux/crserver[0x804a537] > > /opt/cr/bin/Linux/crserver[0x804a092] > > /lib/libc.so.6(__libc_start_main+0xa6)[0xb7be23a6] > > /opt/cr/bin/Linux/crserver[0x8049fd1] > > > > The stacktrace from the nVidia SPUs is much less interesting: > > /lib/libpthread.so.0[0xb7afcf37] > > [0xffffe420] > > > > I have noticed that by commenting out > > cr_unpackDispatch.DrawElements( mode, count, type, (void *) > indices); > > in the function crUnpackExtendedDrawElements in the file > unpack_arrays.c > > and rebuilding Chromium I am able to eliminate the segfaults (the > > application still doesn't work, I get some output, but other > things are > > missing). Using gdb I was able to determine that none of my other > > applications cause the crUnpackExtendedDrawElements function to > be called. > > > > Is something wrong with crUnpackExtendedDrawElements? > > crUnpackExtendedDrawElements() should only be getting used if you're > using server-side vertex arrays via the GL_ARB_vertex_buffer_object > extension. Are you? > > Otherwise, we're probably packing/sending DrawElements() by mistake. > What kind of config file are you using? Tilesort? > > -Brian > > |
|
From: James S. <arr...@gm...> - 2006-07-31 20:42:05
|
yes, My application uses glGetString(GL_EXTENSIONS); and strstr to tell if the OpenGL implementation supports GL_ARB_vertex_buffer_object. It uses the extension to speed up rendering of geometry heavy scenes. I think Chromium should either 1) Not segfualt when the extension is used or 2) Not tell the application that it is supported, though, I prefer the first option myself. I am using a basic autodmx config, I changed the basic config a bit to get it to use ssh rather than rsh for starting the crservers, but that is about it. Basically, I have a single tilesort SPU and a render SPU on each of the four backends. Thank you for your time, James Steven Supancic III On 7/31/06, Brian Paul <bri...@tu...> wrote: > > James Supancic wrote: > > segmentation fault in crserver. > > > > I am attempting to run Sauerbraten using Chromium. I have two nVidia and > > two ATI render SPUs. > > All four render SPUs crash, I was able to get the following stack trace > > from the ATI SPUs. > > /lib/libpthread.so.0[0xb7ab5e87] > > [0xffffe420] > > > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb735e87b] > > > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] > > > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] > > > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x7b)[0xb7dfca5f] > > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7dfbf8c] > > > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7df8693] > > /opt/cr/bin/Linux/crserver[0x805657e] > > /opt/cr/bin/Linux/crserver[0x805669f] > > /opt/cr/bin/Linux/crserver[0x8056789] > > /opt/cr/bin/Linux/crserver[0x80567c7] > > /opt/cr/bin/Linux/crserver[0x804a537] > > /opt/cr/bin/Linux/crserver[0x804a092] > > /lib/libc.so.6(__libc_start_main+0xa6)[0xb7be23a6] > > /opt/cr/bin/Linux/crserver[0x8049fd1] > > > > The stacktrace from the nVidia SPUs is much less interesting: > > /lib/libpthread.so.0[0xb7afcf37] > > [0xffffe420] > > > > I have noticed that by commenting out > > cr_unpackDispatch.DrawElements( mode, count, type, (void *) indices); > > in the function crUnpackExtendedDrawElements in the file unpack_arrays.c > > and rebuilding Chromium I am able to eliminate the segfaults (the > > application still doesn't work, I get some output, but other things are > > missing). Using gdb I was able to determine that none of my other > > applications cause the crUnpackExtendedDrawElements function to be > called. > > > > Is something wrong with crUnpackExtendedDrawElements? > > crUnpackExtendedDrawElements() should only be getting used if you're > using server-side vertex arrays via the GL_ARB_vertex_buffer_object > extension. Are you? > > Otherwise, we're probably packing/sending DrawElements() by mistake. > What kind of config file are you using? Tilesort? > > -Brian > |
|
From: Brian P. <bri...@tu...> - 2006-07-31 14:09:53
|
James Supancic wrote: > segmentation fault in crserver. > > I am attempting to run Sauerbraten using Chromium. I have two nVidia and > two ATI render SPUs. > All four render SPUs crash, I was able to get the following stack trace > from the ATI SPUs. > /lib/libpthread.so.0[0xb7ab5e87] > [0xffffe420] > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb735e87b] > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] > /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x7b)[0xb7dfca5f] > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7dfbf8c] > /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7df8693] > /opt/cr/bin/Linux/crserver[0x805657e] > /opt/cr/bin/Linux/crserver[0x805669f] > /opt/cr/bin/Linux/crserver[0x8056789] > /opt/cr/bin/Linux/crserver[0x80567c7] > /opt/cr/bin/Linux/crserver[0x804a537] > /opt/cr/bin/Linux/crserver[0x804a092] > /lib/libc.so.6(__libc_start_main+0xa6)[0xb7be23a6] > /opt/cr/bin/Linux/crserver[0x8049fd1] > > The stacktrace from the nVidia SPUs is much less interesting: > /lib/libpthread.so.0[0xb7afcf37] > [0xffffe420] > > I have noticed that by commenting out > cr_unpackDispatch.DrawElements( mode, count, type, (void *) indices); > in the function crUnpackExtendedDrawElements in the file unpack_arrays.c > and rebuilding Chromium I am able to eliminate the segfaults (the > application still doesn't work, I get some output, but other things are > missing). Using gdb I was able to determine that none of my other > applications cause the crUnpackExtendedDrawElements function to be called. > > Is something wrong with crUnpackExtendedDrawElements? crUnpackExtendedDrawElements() should only be getting used if you're using server-side vertex arrays via the GL_ARB_vertex_buffer_object extension. Are you? Otherwise, we're probably packing/sending DrawElements() by mistake. What kind of config file are you using? Tilesort? -Brian |
|
From: James S. <arr...@gm...> - 2006-07-30 07:21:35
|
segmentation fault in crserver. I am attempting to run Sauerbraten using Chromium. I have two nVidia and two ATI render SPUs. All four render SPUs crash, I was able to get the following stack trace from the ATI SPUs. /lib/libpthread.so.0[0xb7ab5e87] [0xffffe420] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0xb5b)[0xb735e87b] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] /usr/X11R6/lib/modules/dri/fglrx_dri.so(__glim_R300TCLDrawElements+0x129)[0xb735de49] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpackExtendDrawElements+0x7b)[0xb7dfca5f] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so[0xb7dfbf8c] /opt/cr/lib/Linux/libcrserver_crunpacker_copy.so(crUnpack+0x9ed)[0xb7df8693] /opt/cr/bin/Linux/crserver[0x805657e] /opt/cr/bin/Linux/crserver[0x805669f] /opt/cr/bin/Linux/crserver[0x8056789] /opt/cr/bin/Linux/crserver[0x80567c7] /opt/cr/bin/Linux/crserver[0x804a537] /opt/cr/bin/Linux/crserver[0x804a092] /lib/libc.so.6(__libc_start_main+0xa6)[0xb7be23a6] /opt/cr/bin/Linux/crserver[0x8049fd1] The stacktrace from the nVidia SPUs is much less interesting: /lib/libpthread.so.0[0xb7afcf37] [0xffffe420] I have noticed that by commenting out cr_unpackDispatch.DrawElements( mode, count, type, (void *) indices); in the function crUnpackExtendedDrawElements in the file unpack_arrays.c and rebuilding Chromium I am able to eliminate the segfaults (the application still doesn't work, I get some output, but other things are missing). Using gdb I was able to determine that none of my other applications cause the crUnpackExtendedDrawElements function to be called. Is something wrong with crUnpackExtendedDrawElements? Thank you for your time, James Steven Supancic III |
|
From: James S. <arr...@gm...> - 2006-07-30 04:45:48
|
It turns out that I had to set fake_window_dims on the tilesort SPU to get threadtest working with my autodmx.conf. Thank you for your time, James Steven Supancic III |
|
From: James S. <arr...@gm...> - 2006-07-29 04:09:35
|
threadtest fails. I am using Chromium 1.9 (CVS, 7:55 PDT Jul 28 2006). I built my copy of Chromium with THREADSAFE=1 in cr/options.mk . But when I run run threattest -t 1 (I also tried -t 2 and -t 10) it appears to fail. I am using an autodmx configuration. Other applications, such as atlantis, and city run fine. Output from threattest -t 1 follows: CR Warning(delta:25154): the OpenGL faker was loaded without crappfaker! Defaulting to an application id of -1! This won't work if you're debugging a parallel application! In this case, set the CR_APPLICATION_ID_NUMBER environment variable to the right thing (see opengl_stub/load.c) CR Debug(delta:25154): In crNetConnectToServer( "localhost", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10000, with protocol tcpip CR Debug(delta:25154): crNetConnectToServer() failed, freeing the connection CR Warning(delta:25154): Using Chromium configuration for * from /home/arrummzen/.crconfigs CR Debug(delta:25154): Spawning mothership with argv: CR Debug(delta:25154): argv[0] = 'python' CR Debug(delta:25154): argv[1] = '-E' CR Debug(delta:25154): argv[2] = '/home/arrummzen/cr/autodmx.conf' CR Debug(delta:25154): argv[3] = '10055' CR Debug(delta:25154): argv[4] = 'threadtest' This is Chromium, Version 1.9 Autostart for node 192.168.10.106: ['/usr/bin/ssh', '192.168.10.106', "/bin/sh -c 'unset LD_LIBRARY_PATH LD_PRELOAD ; LD_PRELOAD=/lib/libSegFault.so DISPLAY=:0.1 LD_LIBRARY_PATH=/opt/cr/lib/Linux /opt/cr/bin/Linux/crserver -mothership delta:10055'"] Autostart for node 192.168.10.101: ['/usr/bin/ssh', '192.168.10.101', "/bin/sh -c 'unset LD_LIBRARY_PATH LD_PRELOAD ; LD_PRELOAD=/lib/libSegFault.so DISPLAY=:0.0 LD_LIBRARY_PATH=/opt/cr/lib/Linux /opt/cr/bin/Linux/crserver -mothership delta:10055'"] Autostart for node 192.168.10.106: ['/usr/bin/ssh', '192.168.10.106', "/bin/sh -c 'unset LD_LIBRARY_PATH LD_PRELOAD ; LD_PRELOAD=/lib/libSegFault.so DISPLAY=:0.0 LD_LIBRARY_PATH=/opt/cr/lib/Linux /opt/cr/bin/Linux/crserver -mothership delta:10055'"] Autostart for node 192.168.10.103: ['/usr/bin/ssh', '192.168.10.103', "/bin/sh -c 'unset LD_LIBRARY_PATH LD_PRELOAD ; LD_PRELOAD=/lib/libSegFault.so DISPLAY=:0.0 LD_LIBRARY_PATH=/opt/cr/lib/Linux /opt/cr/bin/Linux/crserver -mothership delta:10055'"] Start a crappfaker on delta CR Debug(alpha:16951): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(alpha:16951): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16951): Done connecting to delta:10055 (swapping=0) CR Debug(alpha:16950): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(alpha:16950): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16950): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25176): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25176): Connecting to delta on port 10055, with protocol tcpip CR Debug(delta:25176): Done connecting to delta:10055 (swapping=0) CR Debug(root:5753): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(root:5753): Connecting to delta on port 10055, with protocol tcpip CR Debug(root:5753): Done connecting to delta:10055 (swapping=0) Mothership signalling spawning process 25154 CR Debug(delta:25154): Got signal 10: mothership is awake! CR Debug(delta:25154): Mothership is awake! CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16951): CRServer: my SPU chain: 1 1 render CR Debug(alpha:16951): SPU 1/1: (1) "render" CR Debug(alpha:16950): CRServer: my SPU chain: 1 3 render CR Debug(alpha:16950): SPU 1/1: (3) "render" CR Debug(delta:25176): CRServer: my SPU chain: 1 4 render CR Debug(delta:25176): SPU 1/1: (4) "render" CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(root:5753): CRServer: my SPU chain: 1 2 render CR Debug(root:5753): SPU 1/1: (2) "render" CR Debug(delta:25154): SPU 1/1: (0) "tilesort" CR Debug(alpha:16951): CRServer: my port number is 7004 CR Debug(alpha:16950): CRServer: my port number is 7006 CR Debug(delta:25176): CRServer: my port number is 7007 CR Debug(alpha:16951): Initializing error SPU CR Debug(alpha:16950): Initializing error SPU CR Debug(delta:25176): Initializing error SPU CR Debug(alpha:16951): Initializing render SPU CR Debug(alpha:16951): Render SPU: thread-safe CR Debug(alpha:16951): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(alpha:16951): Connecting to delta on port 10055, with protocol tcpip CR Debug(delta:25176): Initializing render SPU CR Debug(delta:25176): Render SPU: thread-safe CR Debug(delta:25176): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25176): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16950): Initializing render SPU CR Debug(alpha:16950): Render SPU: thread-safe CR Debug(alpha:16950): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(alpha:16950): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16951): Done connecting to delta:10055 (swapping=0) CR Debug(root:5753): CRServer: my port number is 7005 CR Debug(root:5753): Initializing error SPU CR Debug(alpha:16951): Looking for the system's OpenGL library... CR Debug(root:5753): Initializing render SPU CR Debug(root:5753): Render SPU: thread-safe CR Debug(root:5753): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(root:5753): Connecting to delta on port 10055, with protocol tcpip CR Debug(delta:25176): Done connecting to delta:10055 (swapping=0) CR Debug(root:5753): Done connecting to delta:10055 (swapping=0) CR Debug(alpha:16950): Done connecting to delta:10055 (swapping=0) CR Debug(alpha:16951): Found it in default path. CR Debug(alpha:16951): Render SPU: Creating default window (visBits=0x25, id=0) CR Debug(alpha:16951): Render SPU: Opening display 192.168.10.106:0.1 CR Debug(delta:25176): Looking for the system's OpenGL library... CR Debug(root:5753): Looking for the system's OpenGL library... CR Debug(alpha:16950): Looking for the system's OpenGL library... CR Debug(root:5753): Found it in default path. CR Debug(root:5753): Render SPU: Creating default window (visBits=0x25, id=0) CR Debug(root:5753): Render SPU: Opening display 192.168.10.101:0.0 CR Debug(alpha:16950): Found it in default path. CR Debug(alpha:16950): Render SPU: Creating default window (visBits=0x25, id=0) CR Debug(alpha:16950): Render SPU: Opening display 192.168.10.106:0.0 CR Debug(root:5753): Render SPU: Chose visual id=0x26: RGBA=(8,8,8,0) Z=24 stencil=0 double=1 stereo=0 accum=(16,16,16,16) CR Debug(root:5753): Render SPU: Created window 0x400001 on display 192.168.10.101:0.0, Xvisual 0x26 CR Debug(root:5753): Render SPU: actual window x, y, width, height: 0, 0, 256, 256 CR Debug(root:5753): Render SPU: WindowCreate returned 0 (0=normal) CR Debug(root:5753): Render SPU: Creating default context, visBits=0x25 CR Debug(delta:25176): Found it in default path. CR Debug(delta:25176): Render SPU: Creating default window (visBits=0x25, id=0) CR Debug(delta:25176): Render SPU: Opening display 192.168.10.103:0.0 CR Debug(delta:25154): Initializing error SPU CR Debug(delta:25154): Initializing tilesort SPU CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(root:5753): Render SPU: Created DIRECT context (0) on display 192.168.10.101:0.0 for visAttribs 0x25 CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25154): Tilesort SPU: Got the MTU as 10485760 CR Debug(delta:25154): Tilesort SPU: found 4 servers. CR Debug(delta:25154): Getting tile information from servers. CR Debug(delta:25154): Server 1: tcpip://192.168.10.106:7004 CR Debug(delta:25154): Server 2: tcpip://192.168.10.101:7005 CR Debug(delta:25154): Server 3: tcpip://192.168.10.106:7006 CR Debug(delta:25154): Server 4: tcpip://192.168.10.103:7007 CR Debug(delta:25176): Render SPU: Chose visual id=0x26: RGBA=(8,8,8,0) Z=24 stencil=0 double=1 stereo=0 accum=(16,16,16,16) CR Debug(delta:25176): Render SPU: Created window 0x400001 on display 192.168.10.103:0.0, Xvisual 0x26 CR Debug(delta:25176): Render SPU: actual window x, y, width, height: 0, 0, 256, 256 CR Debug(delta:25176): Render SPU: WindowCreate returned 0 (0=normal) CR Warning(delta:25154): Tilesort bucket_mode = Non-Uniform Grid, but tiles don't form a non-uniform grid! Falling back to Test All Tiles mode. CR Debug(delta:25176): Render SPU: Creating default context, visBits=0x25 CR Debug(delta:25154): Tilesort SPU: Total output dimensions = (2560, 1200) CR Debug(delta:25154): In crNetConnectToServer( "tcpip://192.168.10.106:7004", port=7000, mtu=10485760, broker=1 ) CR Debug(delta:25154): Connecting to 192.168.10.106 on port 7004, with protocol tcpip CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(root:5753): Render SPU: GL_VENDOR: NVIDIA Corporation CR Debug(root:5753): Render SPU: GL_RENDERER: GeForce3/AGP/SSE/3DNOW! CR Debug(root:5753): Render SPU: GL_VERSION: 1.5.6 NVIDIA 87.56 CR Debug(root:5753): Render SPU: ---------- End of Init ------------- CR Debug(root:5753): CRServer: my clients: 1 tcpip 0 CR Debug(root:5753): In crNetAcceptClient( protocol="tcpip" port=7005 mtu=10485760 ) CR Debug(delta:25176): Render SPU: Created DIRECT context (0) on display 192.168.10.103:0.0 for visAttribs 0x25 CR Debug(root:5753): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(root:5753): Connecting to delta on port 10055, with protocol tcpip CR Debug(root:5753): Done connecting to delta:10055 (swapping=0) CR Debug(alpha:16951): Render SPU: Chose visual id=0x7c: RGBA=(8,8,8,8) Z=24 stencil=0 double=1 stereo=0 accum=(0,0,0,0) CR Debug(alpha:16951): Render SPU: Created window 0x800002 on display 192.168.10.106:0.1, Xvisual 0x7c CR Debug(alpha:16951): Render SPU: actual window x, y, width, height: 0, 0, 256, 256 CR Debug(alpha:16951): Render SPU: WindowCreate returned 0 (0=normal) CR Debug(alpha:16951): Render SPU: Creating default context, visBits=0x25 CR Debug(alpha:16951): Render SPU: Created DIRECT context (0) on display 192.168.10.106:0.1 for visAttribs 0x25 CR Debug(alpha:16951): Render SPU: GL_VENDOR: ATI Technologies Inc. CR Debug(alpha:16951): Render SPU: GL_RENDERER: MOBILITY RADEON 9600 Generic CR Debug(alpha:16951): Render SPU: GL_VERSION: 2.0.5814 (8.25.18) CR Debug(alpha:16951): Render SPU: ---------- End of Init ------------- CR Debug(alpha:16951): CRServer: my clients: 1 tcpip 0 CR Debug(alpha:16951): In crNetAcceptClient( protocol="tcpip" port=7004 mtu=10485760 ) CR Debug(alpha:16951): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(alpha:16951): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16951): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25154): Done connecting to tcpip://192.168.10.106:7004 (swapping=0) CR Debug(delta:25154): In crNetConnectToServer( "tcpip://192.168.10.101:7005", port=7000, mtu=10485760, broker=1 ) CR Debug(delta:25154): Connecting to 192.168.10.101 on port 7005, with protocol tcpip CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16951): Accepted connection from "delta". CR Debug(alpha:16951): Adding client 0x831e0a8 to the run queue CR Debug(alpha:16951): Added tile: 0, 0 .. 1024, 768 CR Info(alpha:16951): Total output dimensions = (2560, 1200) CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(root:5753): Accepted connection from "delta". CR Debug(root:5753): Adding client 0x81cd990 to the run queue CR Debug(root:5753): Added tile: 0, 0 .. 1280, 1024 CR Debug(delta:25154): Done connecting to tcpip://192.168.10.101:7005 (swapping=0) CR Debug(delta:25154): In crNetConnectToServer( "tcpip://192.168.10.106:7006", port=7000, mtu=10485760, broker=1 ) CR Debug(delta:25154): Connecting to 192.168.10.106 on port 7006, with protocol tcpip CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16950): Render SPU: Chose visual id=0x29: RGBA=(8,8,8,8) Z=24 stencil=0 double=1 stereo=0 accum=(0,0,0,0) CR Debug(alpha:16950): Render SPU: Created window 0x1000002 on display 192.168.10.106:0.0, Xvisual 0x29 CR Debug(alpha:16950): Render SPU: actual window x, y, width, height: 0, 0, 256, 256 CR Debug(alpha:16950): Render SPU: WindowCreate returned 0 (0=normal) CR Debug(alpha:16950): Render SPU: Creating default context, visBits=0x25 CR Info(root:5753): Total output dimensions = (2560, 1200) CR Debug(alpha:16950): Render SPU: Created DIRECT context (0) on display 192.168.10.106:0.0 for visAttribs 0x25 CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(alpha:16950): Render SPU: GL_VENDOR: ATI Technologies Inc. CR Debug(alpha:16950): Render SPU: GL_RENDERER: MOBILITY RADEON 9600 Generic CR Debug(alpha:16950): Render SPU: GL_VERSION: 2.0.5814 (8.25.18) CR Debug(alpha:16950): Render SPU: ---------- End of Init ------------- CR Debug(alpha:16950): CRServer: my clients: 1 tcpip 0 CR Debug(alpha:16950): In crNetAcceptClient( protocol="tcpip" port=7006 mtu=10485760 ) CR Debug(alpha:16950): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(alpha:16950): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16950): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25154): Done connecting to tcpip://192.168.10.106:7006 (swapping=0) CR Debug(delta:25154): In crNetConnectToServer( "tcpip://192.168.10.103:7007", port=7000, mtu=10485760, broker=1 ) CR Debug(delta:25154): Connecting to 192.168.10.103 on port 7007, with protocol tcpip CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16950): Accepted connection from "delta". CR Debug(alpha:16950): Adding client 0x831e0a8 to the run queue CR Debug(alpha:16950): Added tile: 0, 0 .. 1600, 1200 CR Info(alpha:16950): Total output dimensions = (2560, 1200) CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25176): Render SPU: GL_VENDOR: NVIDIA Corporation CR Debug(delta:25176): Render SPU: GL_RENDERER: GeForce 6800 GT/AGP/SSE2 CR Debug(delta:25176): Render SPU: GL_VERSION: 2.0.2 NVIDIA 87.62 CR Debug(delta:25176): Render SPU: ---------- End of Init ------------- CR Debug(delta:25176): CRServer: my clients: 1 tcpip 0 CR Debug(delta:25176): In crNetAcceptClient( protocol="tcpip" port=7007 mtu=10485760 ) CR Debug(delta:25176): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25176): Connecting to delta on port 10055, with protocol tcpip CR Debug(delta:25176): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25154): Done connecting to tcpip://192.168.10.103:7007 (swapping=0) CR Debug(delta:25154): Buffer pool 0x804d778 was empty; allocated new 10485780 byte buffer. CR Debug(delta:25154): Buffer pool 0x804d778 was empty; allocated new 10485780 byte buffer. CR Debug(delta:25154): Buffer pool 0x804d778 was empty; allocated new 10485780 byte buffer. CR Debug(delta:25154): Buffer pool 0x804d778 was empty; allocated new 10485780 byte buffer. CR Debug(delta:25154): Tilesort SPU: Using DMX CR Debug(delta:25154): Looking for the system's OpenGL library... CR Debug(delta:25176): Accepted connection from "delta". CR Debug(delta:25176): Adding client 0x81d3348 to the run queue CR Debug(delta:25176): Added tile: 0, 0 .. 2560, 1024 CR Info(delta:25176): Total output dimensions = (2560, 1200) CR Debug(delta:25154): Found it in default path. CR Debug(delta:25154): Tilesort SPU: ---------- End of Init ------------- CR Debug(delta:25154): Looking for the system's OpenGL library... CR Debug(delta:25154): Found it in default path. CR Debug(alpha:16951): Buffer pool 0x8127620 was empty; allocated new 10485780 byte buffer. CR Debug(alpha:16951): Render SPU: Created window 0x800006 on display 192.168.10.106:0.1, Xvisual 0x7c CR Debug(delta:25154): Buffer pool 0x804d778 was empty; allocated new 10485780 byte buffer. CR Debug(alpha:16951): Render SPU: actual window x, y, width, height: 0, 0, 256, 256 CR Debug(alpha:16951): CRServer: client 0x831e0a8 created new window 1 (SPU window 1) CR Debug(root:5753): Buffer pool 0x8127620 was empty; allocated new 10485780 byte buffer. CR Debug(root:5753): Render SPU: Created window 0x400003 on display 192.168.10.101:0.0, Xvisual 0x26 CR Debug(root:5753): Render SPU: actual window x, y, width, height: 0, 0, 256, 256 CR Debug(root:5753): CRServer: client 0x81cd990 created new window 1 (SPU window 1) CR Debug(alpha:16950): Buffer pool 0x8127620 was empty; allocated new 10485780 byte buffer. CR Debug(alpha:16950): Render SPU: Created window 0x1000006 on display 192.168.10.106:0.0, Xvisual 0x29 CR Debug(alpha:16950): Render SPU: actual window x, y, width, height: 0, 0, 256, 256 CR Debug(alpha:16950): CRServer: client 0x831e0a8 created new window 1 (SPU window 1) CR Debug(delta:25176): Buffer pool 0x8126840 was empty; allocated new 10485780 byte buffer. CR Debug(delta:25176): Render SPU: Created window 0x400003 on display 192.168.10.103:0.0, Xvisual 0x26 CR Debug(delta:25176): Render SPU: actual window x, y, width, height: 0, 0, 256, 256 CR Warning(delta:25154): Tilesort bucket_mode = Non-Uniform Grid, but tiles don't form a non-uniform grid! Falling back to Test All Tiles mode. CR Debug(delta:25154): Tilesort SPU: CreateContext((null), 0x25) CR Debug(delta:25176): CRServer: client 0x81d3348 created new window 1 (SPU window 1) CR Debug(delta:25154): Tilesort SPU: Opened display :4.0 CR Debug(alpha:16951): Render SPU: Created DIRECT context (1) on display 192.168.10.106:0.1 for visAttribs 0x25 CR Debug(root:5753): Render SPU: Created DIRECT context (1) on display 192.168.10.101:0.0 for visAttribs 0x25 CR Debug(alpha:16950): Render SPU: Created DIRECT context (1) on display 192.168.10.106:0.0 for visAttribs 0x25 CR Debug(delta:25154): In crNetConnectToServer( "tcpip://192.168.10.106:7004", port=7000, mtu=10485760, broker=1 ) CR Debug(delta:25154): Connecting to 192.168.10.106 on port 7004, with protocol tcpip CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16951): In crNetAcceptClient( protocol="tcpip" port=7004 mtu=10485760 ) CR Debug(alpha:16951): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(alpha:16951): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16951): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25176): Render SPU: Created DIRECT context (1) on display 192.168.10.103:0.0 for visAttribs 0x25 CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25154): Done connecting to tcpip://192.168.10.106:7004 (swapping=0) CR Debug(delta:25154): In crNetConnectToServer( "tcpip://192.168.10.101:7005", port=7000, mtu=10485760, broker=1 ) CR Debug(delta:25154): Connecting to 192.168.10.101 on port 7005, with protocol tcpip CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(root:5753): In crNetAcceptClient( protocol="tcpip" port=7005 mtu=10485760 ) CR Debug(root:5753): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(root:5753): Connecting to delta on port 10055, with protocol tcpip CR Debug(root:5753): Done connecting to delta:10055 (swapping=0) CR Debug(alpha:16951): Accepted connection from "delta". CR Debug(alpha:16951): Adding client 0x84c6360 to the run queue CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25154): Done connecting to tcpip://192.168.10.101:7005 (swapping=0) CR Debug(delta:25154): In crNetConnectToServer( "tcpip://192.168.10.106:7006", port=7000, mtu=10485760, broker=1 ) CR Debug(delta:25154): Connecting to 192.168.10.106 on port 7006, with protocol tcpip CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16950): In crNetAcceptClient( protocol="tcpip" port=7006 mtu=10485760 ) CR Debug(alpha:16950): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(alpha:16950): Connecting to delta on port 10055, with protocol tcpip CR Debug(root:5753): Accepted connection from "delta". CR Debug(root:5753): Adding client 0x825e050 to the run queue CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(alpha:16950): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25154): Done connecting to tcpip://192.168.10.106:7006 (swapping=0) CR Debug(delta:25154): In crNetConnectToServer( "tcpip://192.168.10.103:7007", port=7000, mtu=10485760, broker=1 ) CR Debug(delta:25154): Connecting to 192.168.10.103 on port 7007, with protocol tcpip CR Debug(delta:25154): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25154): Connecting to delta on port 10055, with protocol tcpip CR Debug(delta:25176): In crNetAcceptClient( protocol="tcpip" port=7007 mtu=10485760 ) CR Debug(delta:25176): In crNetConnectToServer( "delta:10055", port=10000, mtu=8096, broker=0 ) CR Debug(delta:25176): Connecting to delta on port 10055, with protocol tcpip CR Debug(alpha:16950): Accepted connection from "delta". CR Debug(alpha:16950): Adding client 0x84c6360 to the run queue CR Debug(delta:25176): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25154): Done connecting to delta:10055 (swapping=0) CR Debug(delta:25154): Done connecting to tcpip://192.168.10.103:7007 (swapping=0) CR Debug(delta:25154): Buffer pool 0x804d778 was empty; allocated new 10485780 byte buffer. CR Debug(delta:25154): Buffer pool 0x804d778 was empty; allocated new 10485780 byte buffer. CR Debug(delta:25154): Buffer pool 0x804d778 was empty; allocated new 10485780 byte buffer. CR Debug(delta:25176): Accepted connection from "delta". CR Debug(delta:25176): Adding client 0x825d6c0 to the run queue CR Error(delta:25154): Couldn't get the window size in tilesortspu_Viewport! If there is no Window, set fake_window_dims for the tilesort SPU. CR Debug(delta:25154): Cleaning up SPU tilesort CR Error(delta:25154): Assertion failed: pc->currentBuffer, file packer.c, line 5760 CR Debug(delta:25154): Cleaning up SPU tilesort CR Debug(delta:25176): Dead connection (sock=12, host=delta), removing from pool CR Debug(delta:25176): Deleting client 0x81d3348 (0 msgs left) CR Debug(delta:25176): Dead connection (sock=3, host=delta), removing from pool CR Debug(delta:25176): Deleting client 0x825d6c0 (0 msgs left) CR Debug(delta:25176): Last client deleted - empty run queue. CR Debug(delta:25176): Cleaning up SPU render CR Debug(alpha:16951): Dead connection (sock=10, host=delta), removing from pool CR Debug(alpha:16951): Deleting client 0x831e0a8 (0 msgs left) CR Debug(alpha:16951): Dead connection (sock=3, host=delta), removing from pool CR Debug(alpha:16951): Deleting client 0x84c6360 (0 msgs left) CR Debug(alpha:16951): Last client deleted - empty run queue. CR Debug(alpha:16951): Cleaning up SPU render CR Debug(delta:25176): Cleaning up SPU error CR Debug(root:5753): Dead connection (sock=11, host=delta), removing from pool CR Debug(root:5753): Deleting client 0x81cd990 (0 msgs left) CR Debug(root:5753): Dead connection (sock=3, host=delta), removing from pool CR Debug(root:5753): Deleting client 0x825e050 (0 msgs left) CR Debug(root:5753): Last client deleted - empty run queue. CR Debug(root:5753): Cleaning up SPU render CR Debug(root:5753): Cleaning up SPU error CR Debug(alpha:16951): Cleaning up SPU error CR Debug(alpha:16950): Dead connection (sock=10, host=delta), removing from pool CR Debug(alpha:16950): Deleting client 0x831e0a8 (0 msgs left) CR Debug(alpha:16950): Dead connection (sock=3, host=delta), removing from pool CR Debug(alpha:16950): Deleting client 0x84c6360 (0 msgs left) CR Debug(alpha:16950): Last client deleted - empty run queue. CR Debug(alpha:16950): Cleaning up SPU render CR Debug(alpha:16950): Cleaning up SPU error Is this a configuration error on my part, or is something wrong with Chromium? Thank you for your time, James Steven Supancic III |
|
From: Vincent V. <viv...@ir...> - 2006-07-27 20:37:39
|
> Message: 1 > Date: Mon, 24 Jul 2006 22:54:44 -0400 > From: Christopher Andrews <cp...@vt...> > Subject: [Chromium-users] QT > To: chr...@li... > Message-ID: <86E...@vt...> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > I've just started using Chromium and I'm still working out all of its > capabilities. Down in config/Linux.mk I found a section that > "enables" QT. I can't find a single reference in the documentation > (or anywhere else for that matter) as to what that actually does (or > is supposed to do). Can anyone out there enlighten me? > > C. Andrews > > Hi, It could be a deprecated requirement for a QT graphical configuration tool. The actual one is based on wxPython. wxWindows stuffs were such a royal PITA to install on one of my old configuration, that I actually tried to compile the QT tool (without any success as you could guess). http://chromium.sourceforge.net/doc/configtool.html Vincent. |
|
From: Christopher A. <cp...@vt...> - 2006-07-25 02:55:01
|
I've just started using Chromium and I'm still working out all of its capabilities. Down in config/Linux.mk I found a section that "enables" QT. I can't find a single reference in the documentation (or anywhere else for that matter) as to what that actually does (or is supposed to do). Can anyone out there enlighten me? C. Andrews |
|
From: Eric S. <er...@sa...> - 2006-07-20 22:38:28
|
I checked out chromium from CVS (as of 2006-07-20 15:30PST) to try the =20 changes, but am receiving the following errors/warnings: $ python vade.conf ... (more details in attached chromium-1.9.log) CR Debug(vr-master:11873): Using native GL, app window doesn't meet =20 minimum_window_size CR Debug(vr-master:11872): Buffer pool 0x96077c0 was empty; allocated =20 new 1048596 byte buffer. The problem is that the render nodes do have the tiles showing up and =20 moving as they should, but the app node has a black screen with =20 nothing on it. This exact configuration (all I changed was chromium =20 versions) worked fine with chromium 1.8. Any ideas? -sandalle --=20 Eric Sandall | Source Mage GNU/Linux Developer eric at sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Brian P. <bri...@tu...> - 2006-07-13 15:20:22
|
David Lee wrote: > I am currently using Opteron machines and Chromium version 1.9rc3, and > it appears as if the problem is related to the version of OpenGL > (32/64) on the app/server nodes. > > When running an application that uses the 64bit version of OpenGL in > /usr/lib64, everything seems to work fine, but when running a app that > tries to use 32bit OpenGL in /usr/lib (Nvidia's 32 bit compatibility > libraries) then the TileSort SPU does not load and the application > launches immediately after launching the crappfaker command. > > I am guessing that chromium is only intercepting 64bit opengl calls. > Is there a way to recompile chromium so that it intercepts all of the > 32bit opengl calls? You can build a 32-bit Chromium on a 64-bit system if you set FORCE_32BIT_ABI=1 in options.mk You may need to get Chromium out of CVS for that. -Brian |
|
From: John H. <jo...@co...> - 2006-07-13 15:20:15
|
On Thu, 13 Jul 2006, David Lee wrote:
> I am currently using Opteron machines and Chromium version 1.9rc3, and
> it appears as if the problem is related to the version of OpenGL
> (32/64) on the app/server nodes.
>
> When running an application that uses the 64bit version of OpenGL in
> /usr/lib64, everything seems to work fine, but when running a app that
> tries to use 32bit OpenGL in /usr/lib (Nvidia's 32 bit compatibility
> libraries) then the TileSort SPU does not load and the application
> launches immediately after launching the crappfaker command.
>
> I am guessing that chromium is only intercepting 64bit opengl calls.
> Is there a way to recompile chromium so that it intercepts all of the
> 32bit opengl calls?
I've got the exact same setup, but it's not bitten yet as I'm solely using
64bit code.
Could you not just build one Chromium 32bit and one 64bit?
I suspect it's not to do with not intercepting. I assume crapfaker can only
work with a binary that matches its architecture (effectively the LD_PRELOAD
would fail with the wrong arch).
Installing a 32 and a 64 version and having the LD_PRELOAD set to both might
work? The runtime linker is certainly sane enough to ignore libraries that
are for the wrong arch.
jh
--
"We are what we repeatedly do. Excellence, then, is not an act, but a habit."
-- Aristotle
|
|
From: David L. <dab...@gm...> - 2006-07-13 15:10:40
|
I am currently using Opteron machines and Chromium version 1.9rc3, and it appears as if the problem is related to the version of OpenGL (32/64) on the app/server nodes. When running an application that uses the 64bit version of OpenGL in /usr/lib64, everything seems to work fine, but when running a app that tries to use 32bit OpenGL in /usr/lib (Nvidia's 32 bit compatibility libraries) then the TileSort SPU does not load and the application launches immediately after launching the crappfaker command. I am guessing that chromium is only intercepting 64bit opengl calls. Is there a way to recompile chromium so that it intercepts all of the 32bit opengl calls? -David Lee On 7/12/06, Brian Paul <bri...@tu...> wrote: > David Lee wrote: > > Hello, > > I am trying to use Chromium to display OpenGL content on a 2x3 tiled > > display. Test applications such as "City" and "glxgears" works, but > > when trying other applications such as a Java3D application or > > something like ppracer (tuxracer) the application launches immediately > > after initiating the crappfaker command whereas with "City" and > > "glxgears", the application launches on the tiled display after all of > > the crserver commands are issued on the server nodes. Nothing seems to > > error out. > > > > [appserver] > > The command which I issue is as follows: > > > >>python configscript.conf application_name > > > > > > [appserver] > > > >>crappfaker > > > > [with applications that are successfully redirected to the server > > nodes nothing happens. applications which are not successfully > > redirected launch immediately] > > > > [servernode1] > > crserver > > [servernode2] > > crserver > > > > [if everything working correctly, application launches on all displays] > > > > I suspect that the applications are not loading the crfaker library. I > > have tried creating links to the crfaker library and adding the path > > to my bash config with no success. Any ideas? > > Are you running the app directly from the shell, or using crappfaker? > > If the former, and you've setup a libGL -> libcrfaker symlink, etc. > you can run 'ldd' on the app and it should tell you which shared > libraries it's using. I'd try that. > > -Brian > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Chromium-users mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-users > |
|
From: Brian P. <bri...@tu...> - 2006-07-12 23:14:51
|
David Lee wrote: > Hello, > I am trying to use Chromium to display OpenGL content on a 2x3 tiled > display. Test applications such as "City" and "glxgears" works, but > when trying other applications such as a Java3D application or > something like ppracer (tuxracer) the application launches immediately > after initiating the crappfaker command whereas with "City" and > "glxgears", the application launches on the tiled display after all of > the crserver commands are issued on the server nodes. Nothing seems to > error out. > > [appserver] > The command which I issue is as follows: > >>python configscript.conf application_name > > > [appserver] > >>crappfaker > > [with applications that are successfully redirected to the server > nodes nothing happens. applications which are not successfully > redirected launch immediately] > > [servernode1] > crserver > [servernode2] > crserver > > [if everything working correctly, application launches on all displays] > > I suspect that the applications are not loading the crfaker library. I > have tried creating links to the crfaker library and adding the path > to my bash config with no success. Any ideas? Are you running the app directly from the shell, or using crappfaker? If the former, and you've setup a libGL -> libcrfaker symlink, etc. you can run 'ldd' on the app and it should tell you which shared libraries it's using. I'd try that. -Brian |
9 messages has been excluded from this view by a project administrator.
