From: Joel W. <we...@st...> - 2004-11-05 20:15:11
|
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 > > > > |