From: Donald Tidrow (dtidrow++at++patriot.net)
Date: 06/16/2003 14:50:21
On Mon, 16 Jun 2003, Allan Schaffer wrote:
> Hi Mike,
>
> Stephens, Mike ERDC-ITL-MS Contractor wrote:
> > i was wondering if there is any way to have multiple shared arenas in
> > performer?
>
> Yikes. The literal answer may be yes; you could probably create your
> own arena handles separate from Performer's -- see "usinit()" -- and
> then usmalloc/usfree data from them. But the practical answer is most
> likely to be "no" since these memory chunks wouldn't be pfMalloc'd and
> therefore would be missing the pfMemory header. That in turn probably
> has some workarounds, like creating tiny pfMalloc'd objects in the main
> arena that have pointers to arena#2-allocated data. It definitely would
> not work for pfNodes but might for simple pfObjects. As I said, yikes -
> this probably is not the path to take.
>
> > my problem is i am loading a bunch of models that go into a switch to be
> > played
> > as a sequence of time steps. the models are at times large and need say
> > 8-16GB of shared memory to stuff them into.
> > i run out of the default shared memory arena.
> > for 32 bit apps this is around 2 GB for 64 bit seems to be around 4GB.
> > is this correct? ( i can't seem to get it any higher no matter what i do.)
>
> The trick with the shared memory arena is that it must be a single,
> contiguous region of physical memory. The problem frequently is that
> system DSOs (including Performer DSOs) get sprinkled around in the
> address space and make it hard to create a big arena.
Still haven't fixed this? There's a nice big hole in the N32 default
memory map (starting at 0x4000000) that I always remapped the Performer
DSO's to. Would be nice if they were distributed that way.
>
> I think? the maximum arena size for N32 is indeed 2GB. I don't know the
> practical limit for 64-bit but it should be very large.
>
The largest I was ever able to get in N32 was something like 1.6G-1.7G,
the remainder of the 2Gb address space was taken up by code, heap, and
DSO's (after remapping the Performer and other DSO's into memory below
the code/heap space). IIRC, we could get a _large_ (>4Gb) pfSharedArena
when compiled in 64-bit mode - actually started paging on a 5Gb machine.
> Have you tried the "remapLibs" tools? In 2.5 & above we ship
> /usr/share/Performer/src/tools/remapLibs/ ..which will shuffle all
> your DSOs around and try to make a bigger memory region. The version
> there is for 32-bit but it could be made 64-bit friendly with a bit of
> tinkering.
Shouldn't need to do this, just set PFSHAREDBASE/PFSHAREDSIZE
appropriately.
>
> Allan
> --
> Allan Schaffer allan++at++sgi.com
> Engr. Manager, Core Rendering 1-650-933-2160
> Silicon Graphics http://www.sgi.com
>
> -----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------
>
--- In October 1997, three computer lab staffers disappeared from the server room while debugging a mysterious router problem.One year later, their packet logs were found...
The Blair Switch Project
-------------------- | Don Tidrow | | Vis-Sim Geek | --------------------
This archive was generated by hypermail 2b29 : Mon Jun 16 2003 - 14:52:09 PDT