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

Re: [Chromium-dev] Fix to comm buffer leak for upstream-going messages

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

bri...@tu... said:
> The above change to the pack SPU causes an assertion failure for me.
> If you compile chromium with RELEASE=0 and test with crdemo.conf and
> TCP/IP you'll see it.

> If I find time later, I'll try to narrow down the cause.

> -Brian

OK, the conflict is happening because teac.c was written before the days of 
BufferPool stuff and was never updated.  I'm trying to figure out how they 
work now...

-Joel

Re: [Chromium-dev] Add a '-timeout' flag to fonttest

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

Joel Welling wrote:
> Hi folks;
>   Any objection to my checking in a change to fonttest to add a -timeout flag? 
>  The flag just causes it to exit after a certain number of milliseconds; we 
> use it here to do an automatic system test.

Sounds OK to me.  Though, if it's anything non-trivial, perhaps 
whipping up a new program would be better.

-Brian

Re: [Chromium-dev] Fix to comm buffer leak for upstream-going messages

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

Joel Welling wrote:
> Hi folks;
>   It looks to me like every time a CR_MESSAGE_READ_PIXELS, WRITEBACK, or 
> READBACK is sent upstream the communications buffer is never freed.  I have a 
> patch to packspu_net.c, replicatespu_net.c, tilesortspu_net.c, and net.c where 
> crNetFree(conn,buf); is added after the appropriate bit of the case 
> statements.  For example, in packspu_net.c the code becomes:
> 
>   		case CR_MESSAGE_READ_PIXELS:
>   			packspuReadPixels( &(msg->readPixels), len );
>   			crNetFree(conn,buf);
>   			break;
>   		case CR_MESSAGE_WRITEBACK:
>   			packspuWriteback( &(msg->writeback) );
>   			crNetFree(conn,buf);
>   			break;
>   		case CR_MESSAGE_READBACK:
>   			packspuReadback( &(msg->readback), len );
>   			crNetFree(conn,buf);
>   			break;
>   		default:
>   			/*crWarning( "Why is the pack SPU getting a message of type 0x%x?", msg->
> type ); */
> 
>   Before I check this in, can someone who knows the network layer look at this 
> and verify that I'm talking sense?  I know this fix allows my application to 
> run on Quadrics without running out of Quadrics card memory.

The above change to the pack SPU causes an assertion failure for me. 
If you compile chromium with RELEASE=0 and test with crdemo.conf and 
TCP/IP you'll see it.

If I find time later, I'll try to narrow down the cause.

-Brian

Re: [Chromium-dev] Fix to comm buffer leak for upstream-going messages

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

This looks like a sane change to me at quick glance, but I'd have to 
trace through the network layer more carefully to be sure.  The only 
concern I have is whether there is a possible race, but it looks like 
that is handled through locking in the network layer.  I'd say check it 
in and people can yell and scream if it causes badness.  This might fix 
some allocation stumbling in the tcpip layer as well since we will 
recover buffers correctly. 

However, a cleaner change would probably to be to look at the network 
layer as a whole to see why messages are not being freed on completion 
notification.  This example is more evidence that we need to take a hard 
look at the network layer and possibly rewrite some of the core.

-Mike

Joel Welling wrote:

>Hi folks;
>  It looks to me like every time a CR_MESSAGE_READ_PIXELS, WRITEBACK, or 
>READBACK is sent upstream the communications buffer is never freed.  I have a 
>patch to packspu_net.c, replicatespu_net.c, tilesortspu_net.c, and net.c where 
>crNetFree(conn,buf); is added after the appropriate bit of the case 
>statements.  For example, in packspu_net.c the code becomes:
>
>  		case CR_MESSAGE_READ_PIXELS:
>  			packspuReadPixels( &(msg->readPixels), len );
>  			crNetFree(conn,buf);
>  			break;
>  		case CR_MESSAGE_WRITEBACK:
>  			packspuWriteback( &(msg->writeback) );
>  			crNetFree(conn,buf);
>  			break;
>  		case CR_MESSAGE_READBACK:
>  			packspuReadback( &(msg->readback), len );
>  			crNetFree(conn,buf);
>  			break;
>  		default:
>  			/*crWarning( "Why is the pack SPU getting a message of type 0x%x?", msg->
>type ); */
>
>  Before I check this in, can someone who knows the network layer look at this 
>and verify that I'm talking sense?  I know this fix allows my application to 
>run on Quadrics without running out of Quadrics card memory.
>
>Thanks,
>-Joel
> we...@ps...
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Chromium-dev mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>  
>

[Chromium-dev] Fix to comm buffer leak for upstream-going messages

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

Hi folks;
  It looks to me like every time a CR_MESSAGE_READ_PIXELS, WRITEBACK, or 
READBACK is sent upstream the communications buffer is never freed.  I have a 
patch to packspu_net.c, replicatespu_net.c, tilesortspu_net.c, and net.c where 
crNetFree(conn,buf); is added after the appropriate bit of the case 
statements.  For example, in packspu_net.c the code becomes:

  		case CR_MESSAGE_READ_PIXELS:
  			packspuReadPixels( &(msg->readPixels), len );
  			crNetFree(conn,buf);
  			break;
  		case CR_MESSAGE_WRITEBACK:
  			packspuWriteback( &(msg->writeback) );
  			crNetFree(conn,buf);
  			break;
  		case CR_MESSAGE_READBACK:
  			packspuReadback( &(msg->readback), len );
  			crNetFree(conn,buf);
  			break;
  		default:
  			/*crWarning( "Why is the pack SPU getting a message of type 0x%x?", msg->
type ); */

  Before I check this in, can someone who knows the network layer look at this 
and verify that I'm talking sense?  I know this fix allows my application to 
run on Quadrics without running out of Quadrics card memory.

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

[Chromium-dev] Add a '-timeout' flag to fonttest

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

Hi folks;
  Any objection to my checking in a change to fonttest to add a -timeout flag? 
 The flag just causes it to exit after a certain number of milliseconds; we 
use it here to do an automatic system test.

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

Re: [Chromium-dev] Comm buffer leak for upstream-going messages?

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

After I finish exams next week, I'll start tracking this back down.  The 
main issue for me is that I run MVAPICH/-2 to get IB performance.  To 
really test and be involved, I'll need people who are willing to help.  
This will mean running LAM MPI-2.  The code is known to work for simple 
cases, but has never been really beat on.  Since support will require a 
specific MPI implementation, it will have to be a compile option like 
the other highspeed network layers.  We will also need to revisit 
non-blocking communication support in the network layer. 

I'll probably hold off on this until a Chromium 1.8 release goes out the 
door.  Those that are willing to help get the code up to snuff, please 
send me an email privately and we'll work with SGI to get the code into 
Chromium.

-Mike

Sean Ahern wrote:

>Mike Houston wrote:
>  
>
>>We will hopefully have an MPI-2 network layer soon for Chromium that 
>>might solve these issues for the most part assuming your hardware is 
>>supported by LAM MPI-2.  The good folks at SGI have done the initial 
>>work and I'm waiting for the code to be patched to run with the current 
>>tree.  If there is enough interest, I might be able to get SGI to dump 
>>the code into the tree and then we can all bang it into shape. 
>>    
>>
>
>I'm very interested in an MPI layer for Chromium.  More so than an SDP
>version.  As for whether it should go in the tree or not...  as long as
>it's possible to disable it at build time until it's fully beaten on, I
>don't see any reason why not.
>
>  
>
>>The other option is to move all of the network layers over to a socket 
>>version (SDP, Sockets-GM, etc).  SDP with Infiniband works great.  ;-)  
>>Even better with AIO.
>>    
>>
>
>-Sean
>
>__
>sea...@ll...
>925-422-1648
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Chromium-dev mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>  
>

[Chromium-dev] Chromium 1.8 release?

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

I think it would be nice to wrap up and release Chromium 1.8 sometime 
this month.  The last release was back in April.

I'll try to start running through the test plan in my spare time. 
Let's try to avoid checking in any potentially disruptive changes. 
Speak up if you have anything that should be included in 1.8.

-Brian

Re: [Chromium-dev] Comm buffer leak for upstream-going messages?

[Sean A. <sea...@ll...>]

Mike Houston wrote:
> We will hopefully have an MPI-2 network layer soon for Chromium that 
> might solve these issues for the most part assuming your hardware is 
> supported by LAM MPI-2.  The good folks at SGI have done the initial 
> work and I'm waiting for the code to be patched to run with the current 
> tree.  If there is enough interest, I might be able to get SGI to dump 
> the code into the tree and then we can all bang it into shape. 

I'm very interested in an MPI layer for Chromium.  More so than an SDP
version.  As for whether it should go in the tree or not...  as long as
it's possible to disable it at build time until it's fully beaten on, I
don't see any reason why not.

> The other option is to move all of the network layers over to a socket 
> version (SDP, Sockets-GM, etc).  SDP with Infiniband works great.  ;-)  
> Even better with AIO.

-Sean

__
sea...@ll...
925-422-1648

Re: [Chromium-dev] Comm buffer leak for upstream-going messages?

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

Hi Mike;

> I don't know the quadrics code very well, but my guess is that large 
> userspace messages, like textures and readpixels calls, are not getting 
> freed correctly.  The general problem with the current network layer is 
> that we need to use fixed size buffers for general traffic so we can 
> pack things on the wire correctly.  However, when you have big data 
> sends, the highspeed layers break the large message into many smaller 
> messages.  If those aren't getting freed correctly, then you will run 
> out of memory on the board.  Are you running out of memory on the send 
> or recv side?

I'm running out of memory on the application (client) side.  I have 
instrumented things just as you describe, and I see the crNetFrees happening 
on the server side but not on the client side.  For example, when the app 
calls glGetError() a Quadrics message is sent downstream (and properly freed 
at the server end), and a reply message is generated at the server and 
received at the client end.  However, the buffer that comes back up with the 
reply message is never freed.

-Joel

> 
> The only real way to track this down is to place crDebug's throughout 
> the teac code and track every message moving through the layer to see 
> why messages sent or received are not getting freed.  But, I would first 
> look at the large send code.
> 
> We will hopefully have an MPI-2 network layer soon for Chromium that 
> might solve these issues for the most part assuming your hardware is 
> supported by LAM MPI-2.  The good folks at SGI have done the initial 
> work and I'm waiting for the code to be patched to run with the current 
> tree.  If there is enough interest, I might be able to get SGI to dump 
> the code into the tree and then we can all bang it into shape. 
> 
> The other option is to move all of the network layers over to a socket 
> version (SDP, Sockets-GM, etc).  SDP with Infiniband works great.  ;-)  
> Even better with AIO.
> 
> -Mike
> 
> Joel Welling wrote:
> 
> >Hi folks;
> >  I'm trying to integrate ParaView and Chromium at the moment, and it's going 
> >very well when I use tcpip networking in Chromium.  When I substitute Quadrics 
> >Teac networking it runs for a while and then fails because the Quadrics card 
> >runs out of on-board memory, which in turn seems to happen because 
> >upstream-going messages (like the results of glGet...() and glReadPixels()) 
> >are not being reclaimed.  Can anyone tell me where this is supposed to happen? 
> > I've looked at the invocations of crNetFree(), and none seem to be in the 
> >obvious places to accomplish this.
> >
> >Thanks,
> >-Joel
> > we...@ps...
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by:
> >Sybase ASE Linux Express Edition - download now for FREE
> >LinuxWorld Reader's Choice Award Winner for best database on Linux.
> >http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> >_______________________________________________
> >Chromium-dev mailing list
> >Chr...@li...
> >https://lists.sourceforge.net/lists/listinfo/chromium-dev
> >  
> >

Re: [Chromium-dev] Comm buffer leak for upstream-going messages?

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

I don't know the quadrics code very well, but my guess is that large 
userspace messages, like textures and readpixels calls, are not getting 
freed correctly.  The general problem with the current network layer is 
that we need to use fixed size buffers for general traffic so we can 
pack things on the wire correctly.  However, when you have big data 
sends, the highspeed layers break the large message into many smaller 
messages.  If those aren't getting freed correctly, then you will run 
out of memory on the board.  Are you running out of memory on the send 
or recv side?

The only real way to track this down is to place crDebug's throughout 
the teac code and track every message moving through the layer to see 
why messages sent or received are not getting freed.  But, I would first 
look at the large send code.

We will hopefully have an MPI-2 network layer soon for Chromium that 
might solve these issues for the most part assuming your hardware is 
supported by LAM MPI-2.  The good folks at SGI have done the initial 
work and I'm waiting for the code to be patched to run with the current 
tree.  If there is enough interest, I might be able to get SGI to dump 
the code into the tree and then we can all bang it into shape. 

The other option is to move all of the network layers over to a socket 
version (SDP, Sockets-GM, etc).  SDP with Infiniband works great.  ;-)  
Even better with AIO.

-Mike

Joel Welling wrote:

>Hi folks;
>  I'm trying to integrate ParaView and Chromium at the moment, and it's going 
>very well when I use tcpip networking in Chromium.  When I substitute Quadrics 
>Teac networking it runs for a while and then fails because the Quadrics card 
>runs out of on-board memory, which in turn seems to happen because 
>upstream-going messages (like the results of glGet...() and glReadPixels()) 
>are not being reclaimed.  Can anyone tell me where this is supposed to happen? 
> I've looked at the invocations of crNetFree(), and none seem to be in the 
>obvious places to accomplish this.
>
>Thanks,
>-Joel
> we...@ps...
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>Chromium-dev mailing list
>Chr...@li...
>https://lists.sourceforge.net/lists/listinfo/chromium-dev
>  
>

[Chromium-dev] Comm buffer leak for upstream-going messages?

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

Hi folks;
  I'm trying to integrate ParaView and Chromium at the moment, and it's going 
very well when I use tcpip networking in Chromium.  When I substitute Quadrics 
Teac networking it runs for a while and then fails because the Quadrics card 
runs out of on-board memory, which in turn seems to happen because 
upstream-going messages (like the results of glGet...() and glReadPixels()) 
are not being reclaimed.  Can anyone tell me where this is supposed to happen? 
 I've looked at the invocations of crNetFree(), and none seem to be in the 
obvious places to accomplish this.

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

Re: [Chromium-dev] Configtool not work with new version of wxPython?

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

Christopher Waters wrote:
> Has anyone else had any problems running the config tool with newer 
> versions of wxPython?  I installed 2.5.2.8 and it doesn't work anymore. 
>  The error I'm getting is:
> Traceback (most recent call last):
>   File "configtool.py", line 15, in ?
>     import graph, crutils
>   File "/cr/mothership/tools/graph.py", line 111, in ?
>     _AppNodeBrush = wxBrush(wxColor(55, 160, 55))
>   File "//Library/Python/2.3/wx/_gdi.py", line 377, in __init__
>     newobj = _gdi_.new_Brush(*args, **kwargs)
> wx._core.PyNoAppError: The wx.App object must be created first!
> 
> 
> As to my professor's suggestion, I checked the wxPython migration guide 
> (http://www.wxpython.org/migrationguide.php), and it seems that since 
> 2.5, the wx.App object must be created first.

I'm sending you a new file to try out.

-Brian

[Chromium-dev] Configtool not work with new version of wxPython?

[Christopher W. <cr...@ms...>]

Has anyone else had any problems running the config tool with newer 
versions of wxPython?  I installed 2.5.2.8 and it doesn't work anymore. 
  The error I'm getting is:
Traceback (most recent call last):
   File "configtool.py", line 15, in ?
     import graph, crutils
   File "/cr/mothership/tools/graph.py", line 111, in ?
     _AppNodeBrush = wxBrush(wxColor(55, 160, 55))
   File "//Library/Python/2.3/wx/_gdi.py", line 377, in __init__
     newobj = _gdi_.new_Brush(*args, **kwargs)
wx._core.PyNoAppError: The wx.App object must be created first!


As to my professor's suggestion, I checked the wxPython migration guide 
(http://www.wxpython.org/migrationguide.php), and it seems that since 
2.5, the wx.App object must be created first.

  -Chris

Re: [Chromium-dev] Chromium on FreeBSD

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

Jeremy W. Sheaffer wrote:
> I just built Chromium under amd64 FreeBSD 5.3 with gcc 3.4.2.  The
> attached patch has all of the changes I had to make.  I think this should
> work for any FreeBSD system, but I don't have any others to test on.

I've checked in your changes.  Thanks.

-Brian

[Chromium-dev] Chromium on FreeBSD

[Jeremy W. S. <jw...@cs...>]

I just built Chromium under amd64 FreeBSD 5.3 with gcc 3.4.2.  The
attached patch has all of the changes I had to make.  I think this should
work for any FreeBSD system, but I don't have any others to test on.

-- 
Jeremy W. Sheaffer
jw...@cs...
http://cs.virginia.edu/~jws9c/



             /*********************************************
             * The Moving Finger writes; and having writ, *
             *    Moves on: nor all thy piety nor wit     *
             *  Shall lure it back to cancel half a line  *
             *  Nor all thy tears wash out a word of it.  *
             *                                            *
             *                       -Omar Khayyam        *
             *********************************************/

Re: [Chromium-dev] Does Chromium has the plan to support shading language?

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

Yuan Guodong wrote:
> Hello,
> 
>  
> 
>          As I know, the OpenGL 2.0 version supports shading language 
> now. So I want to know whether the Chromium project has the plan to 
> support shading language or not?

There are no real plans for it at this time.

-Brian

[Chromium-dev] Does Chromium has the plan to support shading language?

[Yuan G. <yg...@ma...>]

Hello,

 

         As I know, the OpenGL 2.0 version supports shading language now. So
I want to know whether the Chromium project has the plan to support shading
language or not?

 

Guodong

 

[Chromium-dev] Mothership connection brokering bug

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

I believe I've found and fixed a long hidden bug in the mothership
code related to connection brokering.

I'd been testing a simple sort-last configuration with Infiniband.
The app/readback nodes were being automatically started.  Sometimes
everything would start up fine, but other times Chromium would appear
to hang during start-up.  It definitely felt like a timing problem.

The short story is the ib_accept_wait and ib_connect_wait fields on
socket wrappers need to be cleared after they're used/consumed.  This
also needs to be done for SDP and TCPIP.  It looks like GM, Teac and
TSComm are OK.


Here's the long story:

The SocketWrapper class has a number of <protocol>_accept_wait and
<protocol>_connect_wait fields that are used for connection brokering
between Chromium nodes.

When the mothership gets a 'connectionrequest' message, we loop over
all socket wrappers looking for a <protocol>_accept_wait field that's
not 'None' and matches the incoming request's hostname and port
number.  When we find one, that means there was an earlier
"acceptrequest" message that we can now satisfy.  So, we send out two
messages, one to the connect-node and one to the accept-node, to tell
the two endpoints about each other.  Now, we should never re-use the
<protocol>_accept_wait field.  But I found that we were never
resetting the <protocol>_accept_wait field to 'None' so we _were_
reusing the info!

Depending on the protocol, this was harmless or deadly.  With TCP/IP
the messages sent to the connect-node and accept-node were just a
connection ID and endian flag.  It turns out the connection ID isn't
especially significant to the two nodes.  So, returning the same data
to several connections wasn't a big deal.

But with Infiniband there's a whole bunch of other info sent to the
two parties: node_id, server_lid1, server_qp_ous, server_qp, etc.
That lead to trouble.

In my case, several "connectionrequest" messages were all getting
satisfied by just one or two "acceptrequest" messages; the one-to-one
correspondence wasn't enforced.

Conversely, the <protocol>_connect_wait field must also be cleared
when we get a process a "acceptrequest" message for an earlier
"connectionrequest" message.

Interesting, the GM protocol does this already.

Finally, the timing of events was significant.  Depending on the order
in which "connectrequest" and "acceptrequest" messages came in, we
could sometimes get lucky and manage to establish all the connections.
But it was just dumb luck when we did.


If there aren't any concerns, I'll check in my fixes tomorow morning.
I believe the TCP/IP, IB and SDP protocols are the only ones that need
to be fixed.

For the TSComm/Teac protocols, the <protocol>_connect/accept_wait
fields are actually lists.  It appears that entries from the list are
correctly popped/removed after they're used.

-Brian

Re: [Chromium-dev] IB support changes

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

>
> On a related note, I was somewhat uncomfortable checking in Makefile 
> changes, even as minor as this, to the public source, even though 
> there are a few other examples of private or semi-private changes that 
> snuck in here or here, that don't affect other folks...

This probably doesn't matter a lot right now as there are only a few 
Chromium IB users and the IB stacks are still more painful to deal with 
in terms of userspace code than they should be, that a few added steps 
isn't much to deal with.  My main concern is that it's going to be hard 
to deal with bug reports and layer issues unless we are all on the same 
stack.

>
> What's the right way to do this?  Put them in as I did, allowing only 
> extensions of the INCLUDE_DIRS and LDFLAGS variables so that users 
> without the subdirectories won't be affected?  Define a new variable 
> to protect it from anyone who doesn't explicitly set the chosen 
> variable?  Don't do it at all (and maybe clean up the examples that 
> are already there)?

This is why you have to enable IB support to get it compiled in, much 
like the other network layers.  This is probably the best route, but we 
might want to move the definitions of INCLUDE_DIRS and LDFLAGS for IB 
support to options.mk as IB_INCLUDE_DIRS and IB_LDFLAGS so that a user 
knows if they want IB support that they need to modify the IB_SUPPORT 
flag as well as the paths.

>
>
> It may be nice to define some directory outside of the Chromium tree 
> where custom files can be put (for commonly customized things like 
> cr/options.mk, and maybe even custom SPU directories) to avoid both 
> losing track of necessary local changes during a clean check-out, and 
> to avoid accidentally commiting a local change to the repository... 
> but I'm not sure the added utility would be worth the complexity 
> required.

This is always tricky.  I ran into this while doing Raptor.  To build 
Raptor, it has to be in the Chromium tree (cr/progs/raptor).  I just 
kept a separate CVS repository for this in my tree and 'cvs update' 
would do the right thing.  I'm not sure what the best thing is on 
modifying central parts of Chromium for private work.  I would suggest 
branching the tree, but of course then you have sync issues against the 
truck to contend with...  In the end, I'm not sure there is a good answer.

Having a known custom directory that overrides defaults, like 
options.mk, might not be a bad idea.  Custom SPUs are probably better 
done with CVS within CVS like Raptor was done.

Just my 2 cents.  I struggle with this regularly myself.

-Mike

Re: [Chromium-dev] IB support changes

[Robert E. <pa...@tu...>]

Hi, Mike -

> I see you've updated the IB stuff, at least the makefiles, to use the 
> TopSpin stack.  

Yup, only the Makefiles (and one bad header declaration).  I intended the change 
to be completely transparent to those who don't build IB (which I think must be 
nearly all, as the bad header declaration would have stopped any main trunk 
compilation of the IB support), negligible to all builders who don't have the 
TopSpin stack, and essential to those that do.

> This is a really bad idea.  You'll want to run the 
> OpenIB gen1 stack or better yet the Mellanox HPC Gold stack which is 
> public and "easy" to use.

I'll defer to your IB expertise, as I'm not nearly as familiar with all the 
issues regarding competing stacks.

In this particular instance, I was constrained to this particular stack; so 
other issues didn't enter the decision.

On a related note, I was somewhat uncomfortable checking in Makefile changes, 
even as minor as this, to the public source, even though there are a few other 
examples of private or semi-private changes that snuck in here or here, that 
don't affect other folks...

What's the right way to do this?  Put them in as I did, allowing only extensions 
of the INCLUDE_DIRS and LDFLAGS variables so that users without the 
subdirectories won't be affected?  Define a new variable to protect it from 
anyone who doesn't explicitly set the chosen variable?  Don't do it at all (and 
maybe clean up the examples that are already there)?

It may be nice to define some directory outside of the Chromium tree where 
custom files can be put (for commonly customized things like cr/options.mk, and 
maybe even custom SPU directories) to avoid both losing track of necessary local 
changes during a clean check-out, and to avoid accidentally commiting a local 
change to the repository... but I'm not sure the added utility would be worth 
the complexity required.

Thanks for your insights,

Bob Ellison
Tungsten Graphics, Inc.

[Chromium-dev] Re: [Chromium-users] Celestia

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

Ricky Uy wrote:
> I'm getting some weird behavior running Celestia simulations. Here's 
> what I mean:
> 
> A) When I run a simulation without chromium, it's blazing fast.
> 
> B) When I run the simulation with chromium using two machines, one with 
> a pack spu and one with a render spu, it's blazing fast.
> 
> C) When I run the simulation with chromium with two machines just as 
> before, but using one tilesort spu and one render spu (instead of a pack 
> and a render), it's ridiculously slow.
> 
> In both cases B and C, there is only ever one chromium render window. 
> The only variable seems to be the choice of using the pack or the 
> tilesort spu. What's even more weird is that in case C, the machine with 
> the render spu has it's CPU usage at nearly 80% whenever a simulation is 
> run, which is something I've never seen before. The network traffic 
> remains about the same.
> 
> Something I do know is that Celestia uses the pbuffer Nvidia extensions 
> (both video cards I have are Nvidias) and if the extensions aren't 
> supported, then Celestia uses software rendering and goes pretty slow. 
> I'm not sure if that has anything to do with it, that maybe it supports 
> the extension with the pack spu, but is not supported when using 
> tilesort. Does anyone have any clues? Thanks and sorry for the long post.

I've run Celestia on Chromium with tilesort in the past and it seemed 
to run pretty good.

Chromium doesn't support pbuffers at this time.  I'd like to know more 
about Celestia's use of pbuffers.  It sounds strange to me that you'd 
fall back to software rendering if pbuffers aren't available.  I've 
never heard of NVIDIA doing anything like that.

Try running 'top' on the tilesort host to see if it's eating a lot of CPU.

-Brian

[Chromium-dev] IB support changes

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

I see you've updated the IB stuff, at least the makefiles, to use the 
TopSpin stack.  This is a really bad idea.  You'll want to run the 
OpenIB gen1 stack or better yet the Mellanox HPC Gold stack which is 
public and "easy" to use.  The later is now seemingly the standard stack 
until the OpenIB gen2 stack cleans up and goes for Linux kernel inclusion.

The IB (VAPI) code was fragile already.  SDP was better off, but is only 
known to work, albeit hackily, with the OpenIB gen1 stack.  It "should" 
work with the Mellanox HPC Gold stack since it uses the OpenIB SDP and 
OpenSM code.  The main performance issue there is getting AIO up and 
running so we can do non-blocking sends.  But this quickly leads to a 
network layer rewrite so all layers can safely handle non-blocking sends 
and possibly non-blocking receives.  This code has also not been touched 
since the last round of network changes, as can be seen from the compile 
issues, so other things may have changed that might cause issues.

The VAPI code will have to be re-written as the VAPI interface in 
changing in the OpenIB gen2 stack.  When this happens, a decision will 
have to be made if we rewrite the code to use the new VAPI interface, or 
we move to one of the DAPLs, or just settle on an MPI-2 layer for 
Chromium.  SDP has some interesting IP/legal issues and might not be 
supported by all IB vendors in the future.

I have exams for the next 2 weeks, but if all IB Chromium users can move 
to a standard stack, like the Mellanox stack, than we can try to work 
together to sort out the remaining issues towards the end of the month.

-Mike

[Chromium-dev] Celestia

[Ricky Uy <ric...@ya...>]

I'm getting some weird behavior running Celestia simulations. Here's what I mean:

A) When I run a simulation without chromium, it's blazing fast.

B) When I run the simulation with chromium using two machines, one with a pack spu and one with a render spu, it's blazing fast. 

C) When I run the simulation with chromium with two machines just as before, but using one tilesort spu and one render spu (instead of a pack and a render), it's ridiculously slow.

In both cases B and C, there is only ever one chromium render window. The only variable seems to be the choice of using the pack or the tilesort spu. What's even more weird is that in case C, the machine with the render spu has it's CPU usage at nearly 80% whenever a simulation is run, which is something I've never seen before. The network traffic remains about the same.

Something I do know is that Celestia uses the pbuffer Nvidia extensions (both video cards I have are Nvidias) and if the extensions aren't supported, then Celestia uses software rendering and goes pretty slow. I'm not sure if that has anything to do with it, that maybe it supports the extension with the pack spu, but is not supported when using tilesort. Does anyone have any clues? Thanks and sorry for the long post.

Ricky

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Chromium-dev] Another Java Question

[Ricky Uy <ric...@ya...>]

Ok, so I just can't seem to get any JOGL programs to run through Chromium. I remember Dale Beerman saying that he got some Java apps working. Does anyone know how he did it, what binding he used (perhaps something other than JOGL), etc? Any Java success stories would be very, very helpful! Thanks for all the help.

Ricky

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com