From: Allan Schaffer (allan++at++sgi.com)
Date: 05/23/2000 17:02:40
Performers,
IRIX 6.5.8, including Performer 2.2.8, is now available via the usual
distribution channels and for download from http://support.sgi.com.
On the website, click 'IRIX' then 'Maintenance Release', and scroll
to the bottom.
Here's what's new: (from the relnotes)
6.1 Changes_in_IRIS_Performer_2.2.8
6.1.1 Problems_fixed_in_IRIS_Performer_2.2.8
o Access into Shared Memory pages is slow the first time
each page is accessed. This is particularly noticeable
when paging ClipTextures. A workaround has been
implemented (see 'New Features' below). SCR 606004.
o pfFindNode/pfLookupNode cannot find a pfGeode with
pfNode type, though the manpage says that Performer uses
pfIsOfType instead of pfIsExactType for those functions.
This has been fixed so that pfNode/pfLookupNode use
pfIsOfType instead of pfIsExactType semantics (SCR 774905).
o The pfb loader leaks memory when a texture image file
is not available. Loading and deleting a model with one
texture image file missing leaks sizeof(pfTexture) bytes.
6.1.2 New_features_in_IRIS_Performer_2.2.8
6.1.2.1 Arena_Page_Exercising
o When a forked process accesses memory in the shared
arena, the first time it accesses each page is much
slower than accessing that page subsequently. This
problem becomes very pronounced when the forked process
is striding through a large number of pages, such as
sending large amounts of texture from the arena to the
pipes, as is the case with cliptexturing. In this case,
the application will experience performance glitches when
memory regions are accessed for the first time.
The workaround for this problem is to access a memory
location in each page of the arena during program
startup. This workaround makes most sense in the DRAW
process, since it's the one that's affected most due to
its access of large amounts of texture data.
Performer 2.2.8 will touch each arena page in each draw
process if the environment variable
"_PFDRAW_EXERCISE_ARENA" is set. If the environment
variable is set to a numerical value, each draw process
will run through the arena the specified number of times,
reporting how long it took to touch all the pages in each
iteration. It's not necessary to touch each page more
than once except to see the difference in access times to
those pages.
6.1.2.3 Post_lpoint-draw_callback
o Some applications need to draw to the frame buffer
after all other drawing has occurred. In the case where
applications uses a forked LPOINT process, the drawing of
light points happens after the draw callback is invoked,
making it difficult to draw something on top of the light
points.
To get around this problem, Performer 2.2.8 now supports
a post-lpoint-draw callback on pfChannels. To add such a
callback to a pfChannel, use the "PFTRAV_POSTLPOINT"
token to pfChannel::setTravFunc or pfChanTravFunc, for
example:
channel->setTravFunc(PFTRAV_POSTLPOINT, postDrawFunc);
The callback will be invoked regardless of
multiprocessing mode. In applications which fork the
LPOINT process, it will be called after the last light
point has been drawn in each channel. In applications
which do not fork the LPOINT process, the post-lpoint-
draw callback will be invoked immediately after the draw
callback returns. This callback is not reflected in the
stats.
Since Performer 2.2.8 is an eoe update, we can not
distribute header files, so to use the FTRAV_POSTLPOINT
token, you must define it. Include the following lines in
files using the token:
#ifndef PFTRAV_POSTLPOINT
#define PFTRAV_POSTLPOINT 6
#endif
---- Allan Schaffer allan++at++sgi.com Silicon Graphics http://reality.sgi.com/allan
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 17:02:44 PDT