vsmsa (vsmsa++at++club-internet.fr)
Mon, 13 Sep 1999 10:48:40 +0100
Yoel HALLAKOUN
-----Message d'origine-----
De : info-performer Mailing List <info-performer++at++sgi.com>
À : allan++at++holodeck.engr.sgi.com <allan++at++holodeck.engr.sgi.com>
Date : mercredi 8 septembre 1999 10:11
Objet : info-performer Sep 07 1999
>Welcome to the info-performer mailing list DIGEST for September 07 1999
>
>List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Send Submissions to: info-performer++at++sgi.com
> Add/Remove requests: info-performer-request++at++sgi.com
>
>Message Subjects:
>
> 3 Channel
> texture shaking
> Problem Getting over 488MB Shared Arena
> [Fwd: vgFrustum]
> Re: pfLPointState problem
> RE: Isectors and dynamically modified GeoSets
> Re: Problem Getting over 488MB Shared Arena
>
>***************************************************************************
***
>
> From: Devrim Erdem <devrim++at++infotron-tr.com>
> Date: Tue, 07 Sep 1999 16:31:20 +0300
> Subject: 3 Channel
>
>Hi,
>
>I am trying to build an application with 3 displays ( monitors ). I have
three
>channels which are skewed repectively 50, 0, -50 degrees around Z axis.
>
>I plan to put the monitors like this:
> ____1____ ----------------
> / \ ) alpha
> / \
> 2 3
> / \
> / \
>
>But I am not sure what to see on each monitor. When I stand in front of
>a straight road ( in town.flt ) :
>
>-------------------------------
>-------------------------------
>
>The road is rendered as follows with the current channel config :
>
>\ \ / /
> \ \ / /
> \ \ / /
> \ -------------------- / ) beta
> ----------------------/------------
>I am not sure that the angles alplha and beta will compansate each other.
>Additionaly it doesn't look like the right of doing this.
>
>Any resources and ideas would help.
>
>Thank you.
>
>/*===============================================
>M. Devrim Erdem devrim++at++infotron-tr.com
> info(+)TRON, Turkey
>Tel:+90 216 4921002
>Fax:+90 216 3432132
>http://www.infotron-tr.com
>http://abone.turk.net/mderdem
>===============================================*/
>
>
>
>***************************************************************************
***
>
> From: "vsmsa" <vsmsa++at++club-internet.fr>
> Date: Tue, 7 Sep 1999 16:41:47 +0100
> Subject: texture shaking
>
>This is a multi-part message in MIME format.
>
>------=_NextPart_000_001E_01BEF94F.E0D72000
>Content-Type: text/plain;
> charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>I use VEGA/Performer on IR 3 pipe.
>I notice texture shaking on my BDD.
>
>The first reason is that my BDD is too large, so I made tiles of 22000m =
>x13000 m and I use dynamic object with the offset option of object panel =
>on Lynx.
>
>My polygons always shake, but it's better.
>But if I choose a polygone with low coord., I notice that it's the =
>texture which shakes.
>I read the manual pages about texture and detail texture, with a maximum =
>of 11 levels. I respect this.
>
>Do you know some other reasons ?
>
>Yoel HALLAKOUN
>VSM sa
>
>------=_NextPart_000_001E_01BEF94F.E0D72000
>Content-Type: text/html;
> charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
><HTML>
><HEAD>
>
><META content=3Dtext/html;charset=3Diso-8859-1 =
>http-equiv=3DContent-Type>
><META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
></HEAD>
><BODY bgColor=3D#d8d0c8>
><DIV><FONT color=3D#000000 size=3D2>I use VEGA/Performer on IR 3 =
>pipe.</FONT></DIV>
><DIV><FONT color=3D#000000 size=3D2>I notice texture shaking on my =
>BDD.</FONT></DIV>
><DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
><DIV><FONT color=3D#000000 size=3D2>The first reason is that my BDD is =
>too large, so=20
>I made tiles of 22000m x13000 m and I use dynamic object with the offset =
>option=20
>of object panel on Lynx.</FONT></DIV>
><DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
><DIV><FONT color=3D#000000 size=3D2>My polygons always shake, but it's=20
>better.</FONT></DIV>
><DIV><FONT color=3D#000000 size=3D2>But if I choose a polygone with low =
>coord., I=20
>notice that it's the texture which shakes.</FONT></DIV>
><DIV><FONT color=3D#000000 size=3D2>I read the manual pages about =
>texture and detail=20
>texture, with a maximum of 11 levels. I respect this.</FONT></DIV>
><DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
><DIV><FONT color=3D#000000 size=3D2>Do you know some other reasons =
>?</FONT></DIV>
><DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
><DIV><FONT color=3D#000000 size=3D2>Yoel HALLAKOUN</FONT></DIV>
><DIV><FONT color=3D#000000 size=3D2>VSM sa</FONT></DIV></BODY></HTML>
>
>------=_NextPart_000_001E_01BEF94F.E0D72000--
>
>
>***************************************************************************
***
>
> From: DOUGLAS_MASHEK++at++udlp.com
> Date: Tue, 7 Sep 1999 11:20:15 -0500
> Subject: Problem Getting over 488MB Shared Arena
>
>Howdy,
>
>We are running a very large database (in both quantity and size of
geometry) in
>dvMockup 6.0.1 from PTC/Division. The models execute properly when running
in a
>single pipe, single channel mode, but fail when running in a multi-pipe or
>multi-channel mode. The failure is a Performer memory error. The error
suggests
>increasing the PFSHAREDSIZE variable. We have done that, but have run
against a
>hard limit of 488Mb. We have also acquired a memory analysis tool called
"dpa".
>After running it on the visual executable, we discovered that the 488Mb
limit
>resurfaced in the memory listing. We tried several ways to expand the
memory
>regions, but do not have the resources to determine the effective memory
>management. After doing some research through previous Performer mailings,
this
>looks like a common, yet difficult to solve problem. We are looking to
expand
>the pool to roughly 800Mb if possible. The dvMockup tool supports setting
memory
>locations and sizes as long as they fit within the system allocations.
>
>
>Included with this note:
>
>-Performer Crash message
>-"limit" readout of System
>-"dpa" listing of visual resource
>-"hinv" readout of System
>
>
>
>*****Error Message when DVISE crashes: *********************
>
>PF Fatal/Resource(1): pfMemory::new() Unable to allocate 5648
bytes
>from arena 0x422c8000.
> Try using pfSharedArenaSize() or env PFSHAREDSIZE
> to increase the arena size
> (currently 488281.25 KBytes) and check for adequate setrlimit()
> values and available space on swap (or pfTmpDir()).
>PF Warning/Usage(10): pfGetStage() Must call after pfConfig.
>
>
>******"Limit" Settings on 3pipe Onyx2 IR: **********************
>
>cputime unlimited
>filesize unlimited
>datasize 4194304 kbytes
>stacksize 65536 kbytes
>coredumpsize 0 kbytes
>memoryuse 4130928 kbytes
>vmemoryuse 7340032 kbytes
>descriptors 200
>threads 1024
>
>
>*****"dpa" Memory Description for Performer Resource: ******************
>
>pid 94333, process has 66 regions
>addr size(KB) off flags
>---- ---- --- -----
>0x0 16 0x0 READ WRITE COW
>0x200000 16 0x0 READ WRITE COW
>0x10000 16 0x0 READ SHARED PHYS NOTCACHED
>0x2810000 3728 0x0 READ EXEC SHARED
>0x2d70000 4736 0x3a0000 READ WRITE COW
>0x4000000 608 0x0 READ EXEC SHARED
>0x40a4000 48 0x94000 READ WRITE COW
>0x40b0000 144 0x0 READ EXEC SHARED
>0x40e0000 32 0x20000 READ WRITE COW
>0x40e8000 208 0x0 READ EXEC SHARED
>0x4128000 48 0x30000 READ WRITE COW
>0x4138000 64 0x0 READ SHARED
>0x4148000 272 0x0 READ WRITE SHARED
>0x8770000 48 0x0 READ EXEC SHARED
>0x8788000 16 0x8000 READ WRITE COW
>0x9310000 208 0x0 READ EXEC SHARED
>0x9350000 112 0x30000 READ WRITE COW
>0xab60000 528 0x0 READ EXEC SHARED
>0xabf0000 48 0x80000 READ WRITE COW
>0xac70000 320 0x0 READ EXEC SHARED
>0xaccc000 176 0x4c000 READ WRITE COW
>0xafe0000 16 0x0 READ EXEC SHARED
>0xaff0000 16 0x0 READ WRITE COW
>0xb030000 1424 0x0 READ EXEC SHARED
>0xb1a0000 176 0x160000 READ WRITE COW
>0xbfa0000 80 0x0 READ EXEC SHARED
>0xbfc0000 16 0x10000 READ WRITE COW
>0xd360000 320 0x0 READ EXEC SHARED
>0xd3e0000 32 0x50000 READ WRITE COW
>0xd9b0000 240 0x0 READ EXEC SHARED
>0xd9f8000 16 0x38000 READ WRITE COW
>0xda60000 1520 0x0 READ EXEC SHARED
>0xdbec000 80 0x17c000 READ WRITE COW
>0xf440000 96 0x0 READ EXEC SHARED
>0xf464000 16 0x14000 READ WRITE COW
>0xf490000 528 0x0 READ EXEC SHARED
>0xf524000 32 0x84000 READ WRITE COW
>0xf560000 112 0x0 READ EXEC SHARED
>0xf588000 16 0x18000 READ WRITE COW
>0xf590000 1072 0x0 READ EXEC SHARED
>0xf6a8000 64 0x108000 READ WRITE COW
>0xf810000 16 0x0 READ EXEC SHARED
>0xf820000 16 0x0 READ WRITE COW
>0xf920000 48 0x0 READ EXEC SHARED
>0xf93c000 16 0xc000 READ WRITE COW
>0xfa00000 1216 0x0 READ EXEC SHARED
>0xfb40000 80 0x130000 READ WRITE COW
>0xfb60000 144 0x0 READ EXEC SHARED
>0xfbd4000 32 0x24000 READ WRITE COW
>0xfbdc000 48 0x0 READ WRITE COW
>0x10000000 288 0x0 READ EXEC SHARED PRIMARY
>0x10054000 64 0x44000 READ WRITE PRIMARY COW
>0x10064000 800 0x0 READ WRITE BREAK PRIMARY
COW
>0x33300000 10288 0x0 READ WRITE SHARED
>0x3c900000 352 0x0 READ EXEC SHARED
>0x3c988000 112 0x58000 READ WRITE COW
>0x3ca30000 368 0x0 READ EXEC SHARED
>0x3ca9c000 64 0x5c000 READ WRITE COW
>0x42238000 512 0x0 READ WRITE SHARED
>0x422b8000 16 0x0 READ SHARED PHYS NOTCACHED
>0x422c8000 488288 0x0 READ WRITE
>0x5ffa0000 272 0x0 READ EXEC SHARED
>0x5fff4000 48 0x44000 READ WRITE COW
>0x605a0000 64 0x0 READ WRITE SHARED
>0x605b4000 176 0x0 READ WRITE SHARED
>0x7ffc8000 192 0x0 READ WRITE STACK COW
>
>
>*******Hinv of Main System: *************************************
>
>8 195 MHZ IP27 Processors
>CPU: MIPS R10000 Processor Chip Revision: 2.6
>FPU: MIPS R10010 Floating Point Chip Revision: 0.0
>Main memory size: 4096 Mbytes
>Instruction cache size: 32 Kbytes
>Data cache size: 32 Kbytes
>Secondary unified instruction/data cache size: 4 Mbytes
>.
>.
>Graphics board: InfiniteReality2
>Graphics board: InfiniteReality2
>Graphics board: InfiniteReality2
>Integral Fast Ethernet: ef0, version 1, module 1, slot io1, pci 2
>Iris Audio Processor: version RAD revision 7.0, number 1
>Origin BASEIO board, module 1 slot 1: Revision 3
>Origin MSCSI board, module 1 slot 5: Revision 3
>IOC3 external interrupts: 1
>
>
>***************************************************************************
***
>
> From: Ersel ERCEK <ercek++at++venus.aselsan.com.tr>
> Date: Tue, 07 Sep 1999 20:03:38 +0300
> Subject: [Fwd: vgFrustum]
>
>This is a multi-part message in MIME format.
>--------------D132A3233C1F306E92C7FC41
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>
>
>--------------D132A3233C1F306E92C7FC41
>Content-Type: message/rfc822
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>Message-ID: <37D37AA5.1D71E048++at++venus.aselsan.com.tr>
>Date: Mon, 06 Sep 1999 11:26:13 +0300
>From: Ersel ERCEK <ercek++at++venus.aselsan.com.tr>
>X-Mailer: Mozilla 4.07C-SGI [en] (X11; I; IRIX64 6.5 IP30)
>MIME-Version: 1.0
>To: "info-vega++at++paradigmsim.com" <info-vega++at++paradigmsim.com>,
> Vega Support <support++at++paradigmsim.com>
>Subject: vgFrustum
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Hi all;
>
>I try to callback when one object enter symmetric frustum of my
>observer's channel.
>
>I define one frustum type volume and one volume type Isector that has
>related object target and attached to related observer.
>Actually if target and frustum type volume intersect each other then
>there has to be callback.
>
>However I think there is an problem but where;
>
>Have you got any idea? If any I will be too glad.
>
>Thanks in advance.
>
>Ersel ERCEK
>SW Engineer
>Aselsan Inc./ANKARA
> TURKIYE
>
>
>
>--------------D132A3233C1F306E92C7FC41--
>
>
>***************************************************************************
***
>
> From: marcin++at++asmodean.engr.sgi.com (Marcin Romaszewicz)
> Date: Tue, 7 Sep 1999 10:47:59 -0700 (PDT)
> Subject: Re: pfLPointState problem
>
>
>You are seeing a bug which was fixed in 2.2.4. A pfLPointState with an
>intensity of 0 triggers an optimization which has an error in it. Until you
>upgrade, the workaround is to use a very small positive intensity.
>
>-- Marcin
>
>>
>>
>>
>> Hi,
>> When I set the intensity of a pfLPointState to 0.0f, I am getting a
segmentation
>> fault in the draw process. The problem occurs using IRIX 6.5 and
Performer 2.2.1
>> on an O2. The light point state was originally created by the OpenFlight
loader.
>>
>> The same code works without any problems using IRIX 6.5 and Performer
2.2.1 on
>> an Onyx2 system.
>>
>> The following call stack was extracted from the core dump:
>> drawX_LIGHT_POINTS_CvVv() ["gspoint.C":652]
>> drawX_POINTS_CvVv(<stripped>) ["gspoint.C":390]
>> pfDispList::pr_caseDL_DRAW_GSET_GSTATE() ["pfGeoSet.h":613]
>> pfDispList::pr_drawFlat(<stripped>) ["pfDispList.C":3858]
>> pfDispList::draw() ["pfDispList.C":660]
>> pfChannel::pf_drawScene() ["pfChannel.C":2137]
>> pfChannel::pf_draw() ["pfChannel.C":2112]
>> pfDraw() ["pfProcess.C":6348]
>> ccExecutionControl::_draw(this = 0x5802e480, channel = 0x586fa8c0)
>> ["ccExecutionControl.C":870]
>> ccExecutionControl::_drawCallback(channel = 0x586fa8c0, userData = 0x0)
>> ["ccExecutionControl.C":1230]
>> pfChannel::pf_callDrawFunc() ["pfChannel.C":2194]
>> doDraw() ["pfProcess.C":6200]
>> mpDraw() ["pfProcess.C":6890]
>> pfConfig() ["pfProcess.C":2828]
>> ccExecutionControl::configure(this = 0x5802e480, defaultConfigFile =
0x102fc000
>> = "avMain.cfg", argc = 1, argv = 0x7fff2e94) ["ccExecutionControl.C":213]
>> main(argc = 1, argv = 0x7fff2e94) ["avMain.C":60]
>> __start(<stripped>) ["crt1text.s":177]
>>
>> I have found a report of the same problem in the archives (21 May, 1998),
but
>> unfortunately there was no reply stored. Is the O2 behaviour a known
problem, or
>> am I doing something wrong?
>>
>> In the meantime, I have worked around the problem by just setting the
intensity
>> to a very low non-zero value.
>>
>> Thanks,
>> Ian Hawkes
>>
>>
>> -----------------------------------------------------------------------
>> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
>> Submissions: info-performer++at++sgi.com
>> Admin. requests: info-performer-request++at++sgi.com
>>
>
>
>***************************************************************************
***
>
> From: "Dale Newcomb, Jr." <dnewcomb++at++d-a-s.com>
> Date: Tue, 7 Sep 1999 14:29:52 -0400
> Subject: RE: Isectors and dynamically modified GeoSets
> Reply-To: <dnewcomb++at++d-a-s.com>
>
>I found a workaround to this issue, but I don't know if
>it is the ideal way to do it. Basically, it seems that
>Performer caches isector data for performance reasons.
>Since I am modifying the GeoSets, I need to tell Performer
>to re-cache the data. So I added the call:
>
>pfNodeTravMask( pNode, PFTRAV_ISECT, PFTRAV_SELF|PFTAV_DESCEND, \
>PFTRAV_IS_CACHE, PF_OR );
>
>at the end of every frame that I have modified any GeoSets.
>This seems to be giving me good results, but I would like to
>confirm that this is the best choice.
>
>Thanks,
>
>Dale
>
>> -----Original Message-----
>> From: Dale Newcomb, Jr. [mailto:dnewcomb++at++d-a-s.com]
>> Sent: Friday, September 03, 1999 2:01 PM
>> To: Performer Group
>> Subject: Isectors and dynamically modified GeoSets
>>
>>
>> Hi all!
>>
>> We are having a problem right now where our isectors seems to get
>> bad data back. We are using Vega's Z-type isectors on GeoSets that
>> we are dynamically modifying. Before any modifications, the isectors
>> work just fine, returning the Z value for the give X,Y position.
>> Once we have modified the GeoSet, the Z values returned are all wrong.
>> (Normally they are around 100 and they change to around 17,000.)
>>
>> As far as the modifications go, we are basically adding and removing
>> triangles as well as moving vertices in the Z direction. We are also
>> modifying normals and texture coordinates. We are not using a pfFlux
>> as they do not support dynamic sizes for the vertex and polygon lists.
>>
>> This issue is extremely time critical for our client, so any help
>> would be greatly appreciated.
>>
>> Thanks,
>> Dale
>>
>> ----
>> Dale Newcomb, Jr.
>> Principal Engineer
>> Dynamic Animation Systems
>> http://www.d-a-s.com/~dnewcomb
>
>***************************************************************************
***
>
> From: Ran Yakir <rany++at++rtset.co.il>
> Date: Tue, 07 Sep 1999 22:45:37 +0200
> Subject: Re: Problem Getting over 488MB Shared Arena
>
>Hello Douglas,
>
>The problem is that the shared arena has to occupy a continuous range of
memory.
>Since you're shared objects (libraries) are mapped all over the place, the
largest
>chunk of memory that can be allocated is this 488MB. The solution is to map
your
>shared object to some far away place in the address space, where they will
get out
>of the shared arena's way. This, along with changing PFSHAREDBASE, allows
me to get
>a shared arena of 1.4GB !
>Tomorrow, I'll send you the script that maps the shared objects to the end
of the
>address space.
>
>Ran
>
>DOUGLAS_MASHEK++at++udlp.com wrote:
>
>> Howdy,
>>
>> We are running a very large database (in both quantity and size of
geometry) in
>> dvMockup 6.0.1 from PTC/Division. The models execute properly when
running in a
>> single pipe, single channel mode, but fail when running in a multi-pipe
or
>> multi-channel mode. The failure is a Performer memory error. The error
suggests
>> increasing the PFSHAREDSIZE variable. We have done that, but have run
against a
>> hard limit of 488Mb. We have also acquired a memory analysis tool called
"dpa".
>> After running it on the visual executable, we discovered that the 488Mb
limit
>> resurfaced in the memory listing. We tried several ways to expand the
memory
>> regions, but do not have the resources to determine the effective memory
>> management. After doing some research through previous Performer
mailings, this
>> looks like a common, yet difficult to solve problem. We are looking to
expand
>> the pool to roughly 800Mb if possible. The dvMockup tool supports setting
memory
>> locations and sizes as long as they fit within the system allocations.
>>
>> Included with this note:
>>
>> -Performer Crash message
>> -"limit" readout of System
>> -"dpa" listing of visual resource
>> -"hinv" readout of System
>>
>> *****Error Message when DVISE crashes: *********************
>>
>> PF Fatal/Resource(1): pfMemory::new() Unable to allocate 5648
bytes
>> from arena 0x422c8000.
>> Try using pfSharedArenaSize() or env PFSHAREDSIZE
>> to increase the arena size
>> (currently 488281.25 KBytes) and check for adequate setrlimit()
>> values and available space on swap (or pfTmpDir()).
>> PF Warning/Usage(10): pfGetStage() Must call after pfConfig.
>>
>> ******"Limit" Settings on 3pipe Onyx2 IR: **********************
>>
>> cputime unlimited
>> filesize unlimited
>> datasize 4194304 kbytes
>> stacksize 65536 kbytes
>> coredumpsize 0 kbytes
>> memoryuse 4130928 kbytes
>> vmemoryuse 7340032 kbytes
>> descriptors 200
>> threads 1024
>>
>> *****"dpa" Memory Description for Performer Resource:
******************
>>
>> pid 94333, process has 66 regions
>> addr size(KB) off flags
>> ---- ---- --- -----
>> 0x0 16 0x0 READ WRITE COW
>> 0x200000 16 0x0 READ WRITE COW
>> 0x10000 16 0x0 READ SHARED PHYS NOTCACHED
>> 0x2810000 3728 0x0 READ EXEC SHARED
>> 0x2d70000 4736 0x3a0000 READ WRITE COW
>> 0x4000000 608 0x0 READ EXEC SHARED
>> 0x40a4000 48 0x94000 READ WRITE COW
>> 0x40b0000 144 0x0 READ EXEC SHARED
>> 0x40e0000 32 0x20000 READ WRITE COW
>> 0x40e8000 208 0x0 READ EXEC SHARED
>> 0x4128000 48 0x30000 READ WRITE COW
>> 0x4138000 64 0x0 READ SHARED
>> 0x4148000 272 0x0 READ WRITE SHARED
>> 0x8770000 48 0x0 READ EXEC SHARED
>> 0x8788000 16 0x8000 READ WRITE COW
>> 0x9310000 208 0x0 READ EXEC SHARED
>> 0x9350000 112 0x30000 READ WRITE COW
>> 0xab60000 528 0x0 READ EXEC SHARED
>> 0xabf0000 48 0x80000 READ WRITE COW
>> 0xac70000 320 0x0 READ EXEC SHARED
>> 0xaccc000 176 0x4c000 READ WRITE COW
>> 0xafe0000 16 0x0 READ EXEC SHARED
>> 0xaff0000 16 0x0 READ WRITE COW
>> 0xb030000 1424 0x0 READ EXEC SHARED
>> 0xb1a0000 176 0x160000 READ WRITE COW
>> 0xbfa0000 80 0x0 READ EXEC SHARED
>> 0xbfc0000 16 0x10000 READ WRITE COW
>> 0xd360000 320 0x0 READ EXEC SHARED
>> 0xd3e0000 32 0x50000 READ WRITE COW
>> 0xd9b0000 240 0x0 READ EXEC SHARED
>> 0xd9f8000 16 0x38000 READ WRITE COW
>> 0xda60000 1520 0x0 READ EXEC SHARED
>> 0xdbec000 80 0x17c000 READ WRITE COW
>> 0xf440000 96 0x0 READ EXEC SHARED
>> 0xf464000 16 0x14000 READ WRITE COW
>> 0xf490000 528 0x0 READ EXEC SHARED
>> 0xf524000 32 0x84000 READ WRITE COW
>> 0xf560000 112 0x0 READ EXEC SHARED
>> 0xf588000 16 0x18000 READ WRITE COW
>> 0xf590000 1072 0x0 READ EXEC SHARED
>> 0xf6a8000 64 0x108000 READ WRITE COW
>> 0xf810000 16 0x0 READ EXEC SHARED
>> 0xf820000 16 0x0 READ WRITE COW
>> 0xf920000 48 0x0 READ EXEC SHARED
>> 0xf93c000 16 0xc000 READ WRITE COW
>> 0xfa00000 1216 0x0 READ EXEC SHARED
>> 0xfb40000 80 0x130000 READ WRITE COW
>> 0xfb60000 144 0x0 READ EXEC SHARED
>> 0xfbd4000 32 0x24000 READ WRITE COW
>> 0xfbdc000 48 0x0 READ WRITE COW
>> 0x10000000 288 0x0 READ EXEC SHARED PRIMARY
>> 0x10054000 64 0x44000 READ WRITE PRIMARY COW
>> 0x10064000 800 0x0 READ WRITE BREAK PRIMARY
COW
>> 0x33300000 10288 0x0 READ WRITE SHARED
>> 0x3c900000 352 0x0 READ EXEC SHARED
>> 0x3c988000 112 0x58000 READ WRITE COW
>> 0x3ca30000 368 0x0 READ EXEC SHARED
>> 0x3ca9c000 64 0x5c000 READ WRITE COW
>> 0x42238000 512 0x0 READ WRITE SHARED
>> 0x422b8000 16 0x0 READ SHARED PHYS
NOTCACHED
>> 0x422c8000 488288 0x0 READ WRITE
>> 0x5ffa0000 272 0x0 READ EXEC SHARED
>> 0x5fff4000 48 0x44000 READ WRITE COW
>> 0x605a0000 64 0x0 READ WRITE SHARED
>> 0x605b4000 176 0x0 READ WRITE SHARED
>> 0x7ffc8000 192 0x0 READ WRITE STACK COW
>>
>> *******Hinv of Main System: *************************************
>>
>> 8 195 MHZ IP27 Processors
>> CPU: MIPS R10000 Processor Chip Revision: 2.6
>> FPU: MIPS R10010 Floating Point Chip Revision: 0.0
>> Main memory size: 4096 Mbytes
>> Instruction cache size: 32 Kbytes
>> Data cache size: 32 Kbytes
>> Secondary unified instruction/data cache size: 4 Mbytes
>> ..
>> ..
>> Graphics board: InfiniteReality2
>> Graphics board: InfiniteReality2
>> Graphics board: InfiniteReality2
>> Integral Fast Ethernet: ef0, version 1, module 1, slot io1, pci 2
>> Iris Audio Processor: version RAD revision 7.0, number 1
>> Origin BASEIO board, module 1 slot 1: Revision 3
>> Origin MSCSI board, module 1 slot 5: Revision 3
>> IOC3 external interrupts: 1
>>
>> -----------------------------------------------------------------------
>> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
>> Submissions: info-performer++at++sgi.com
>> Admin. requests: info-performer-request++at++sgi.com
>
>--
> __ | Ran Yakir
> /_) _ __ \ / _ / o __ | 28 Ben Gurion St.
>/ )_ (_(_) ) \/ (_(_/<_(_)( | Hod Hasharon 54200
> _/ | Israel
>-------------------------------------+--------------------------------
>At Home : | At Work :
> | RT-SET
> Voice : +972-9-7489974 | Voice : +972-9-9552236
> Fax : +972-9-7422149 | Fax : +972-9-9552239
> E-mail : rany++at++netvision.net.il | E-mail : rany++at++rtset.co.il
>http://rtset.co.il/rany
>
>
>
>***************************************************************************
***
>
This archive was generated by hypermail 2.0b2 on Mon Sep 13 1999 - 01:52:16 PDT