Re: pfAddMPClipTexture in APP only AND pfTexLoad read size

New Message Reply Date view Thread view Subject view Author view

Stephen Maher (maher++at++emsh.gsfc.nasa.gov)
Fri, 1 Oct 1999 16:35:06 -0400


Date: Fri, 01 Oct 1999 13:07:41 -0700
From: Angus Dorbie <dorbie++at++sgi.com>

Stephen Maher wrote:
>
> Hi,
>
> Two unrelated questions:
>
> #1
>
> Is it valid to call pfAddMPClipTexture() in a non-APP process (DBASE)?
>
> When I call it (well, I'm actually calling
> pfuAddMPClipTexturesToPipes()), in APP, things are fine. When I call
> it in DBASE (same cliptexture, etc.) I get
>
> "pfGetMPClipTextureMaster() NULL pfMPClipTexture*"
>

You should do this in the app. The dbase process doesn't have a list of
all created pfObjects and cannot handle this kind of thing.

You could create a scene graph and add children in the same buffer, or
buffer add them to objects known to the app but not the dbase (you have
the pointers from an earlier load of from shared memory), and the
addition will happen in the app after the buffers are merged.

> #2
>
> I'm trying to get my pfApp to utilize some striped disks more
> effectively. Can some pfImplementer tell me if pfTexLoad reads images
> in nice big chunks or stripe-under-utilizing small chunks?

This is determined mainly by the image format. An SGI image format is
quite inefficient, it has RGB data interleaved which has to be arranged
into an OpenGL ready array. That doesn't mean a good loader couldn't
read contiguously and re-read from system memory to rearange but the
loader happens not to do this. Also MIP maps must be generated. Those
are the main reasons we have a pfi image format. You should use that
format if you want to quickly improve performance.

The best possible approach is to use raw data of a known size (maybe
store size in the file name) which you just read in one DMA but MIP maps
complicate things unless you have a tiled approach like clip mapping
where to have consistent large tile size across most levels of MIP. Even
then to get the very best performance there is a fairly complex process
of making sure the data is striped correctly such that you can optimally
dma at high speed from disk straight to memory. This is really only
worth attempting when you want absolute best performance from disk
arrays and your images are around 1kx1k in size and probably also that
the images are all of a similar size for alignment purposes.

Try using pfi with embeded MIP maps and see if that gets you what you
want.

Cheers,Angus.

-- 
"One of the best-known folk theorems of software engineering is that
60% to 75% of conventional software projects are either never
completed or rejected by their intended users. If that range is
anywhere near true (and I've never met a manager of any experience
who disputes it) then more projects than not are being aimed at goals
which are either (a) not realistically attainable, or (b) just plain
wrong."
                 Eric S. Raymond - The Cathedral and The Bazaar

For advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/

----- End forwarded message -----

-- 
stephen.maher++at++gsfc.nasa.gov (301) 286-3368  fax:(301) 286-1776
http://holodeck.gsfc.nasa.gov/vr/vr.html
http://svs.gsfc.nasa.gov   http://www.digitalearth.gov
NASA Goddard Space Flight Center

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Fri Oct 01 1999 - 13:35:12 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.