From: Mario Veraart (eagleOne++at++zonnet.nl)
Date: 04/12/2000 13:15:52
Hello,
I will try to give an impression of the news that was presented at the
Friends of Performer meeting at the ITEC 2000 conference in The Hague.
The meeting time was 15:30 for drinks and snacks.
The talks started at about 16:00
All this is from my memory and notes. Not SGI points of view.
If I'm wrong and people of SGI are allowed to give the correct info
please correct me.
Some of the sheets went so fast I could not see them completely or just
get a glimpse of them. So not all said or visisble is in here.
The first to give a talk was the new product manager Kimberly Neff.
She talked about the new release of 'OpenGL|Performer'. Notice the name
change and writing from 'Iris Performer' to 'OpenGL|Performer'. This is
to reflect the new vision of SGI about the product Performer. In the
new release, 2.4, IrisGL will not be supported any more. There will be
support in the 2.2.x releases but not any new features. It looks as if
everybody has moved to OpenGL and there are no new application made for
IrisGL. An also to point out the fact that the Performer library source
code will be the same for Irix and Linux. To reflect this and OpenGL
being a kind of standard in the VisSim world. This means you can develop
your app ones and decide on other factors, money, on what platform to
run.
The release date for OpenGL|Performer will be at IITSEC 2000. Both Irix
and Linux versions. There will be complete API update, rewrite of man
pages etc. There will be no binary compatibility with previous releases.
There will be quarterly updates for Irix and Linux, at about the same
day. These will be bug fixes and such. Just like the 2.2.x updates.
The changes in 2.4
o Better Multiprocess Scalability, rewrite of code.
The addition of every pipe added 1 ms extra to the APP time.
Not very noticable for 1,2 or 3 pipes but very well if you
have 8 or 9 pipes and want to keep 60 Hz frame rate.
o Multiple processes can be on the same CPU
Example: APP and DBASE can run on the same CPU
(with a little priority setting)
o Multi Texture (like DOOM and Quake)
No performance degradation
Handled by the new feature pfShader (see later on).
o More flexible LOD evaluation
Not just model swith (but dynamic polygon decimation [MV])
o double precision pfDCS (finally)
for large databases
o DPLEX
o more powerful pfLinux implementation
o Advanced VisSim Features
(if they are there or if there is a method of implementing them
more easily was not clear, maybe done with the pfShader)
- rotor wash
- specular high light
- phong shading
- environment map
- layered fog
- bump mapping
- projected texture
Then Jenny Zhao took over
She talked about Multipass rendering.
It will put in the new release of performer. Because everybody wants to
use it but it requires a lot of OpenGL wizz code. In secret SGI has put
a team on a project called 'Shader Library'. It's task was to come up
with a compiler that translates a script to multipass render code. After
about 2 years the product is ready to be released, beta tested. And the
performer team has implemented a pfShader that can read the output of
the shader-compiler.
script ---> shader compiler ---> shader file ---> pfShader
We have seen early test scripts and they look simple and short for the
task that the example program was doing. Jenny told about an example
made by the shader team to render a realistic apple in 800 passes. So it
is capable of doing a 2 pass rendering or a very complex one. You can,
if you think you are smarter than the shader team, make your own shader
compiler, or use the API that comes with the pfShader and implement the
multipass that way.
Using the pfShader gives performer the opportunity to do some sorting
and render the similar passes together and such avoid extra state
changes.
next sheet was a bit vage
'Distance Collaboration'
o TACOM project
o Orbit - network transport layer
o Performer notification
scenegraph change notification
Next speaker was Allan Shaffer about pfLinux.
o Current release is 2.3, named mongoose.
o It's free.
o API compatible with performer 2.2
o Last download count figure: 25302
There was a lottery about the figure, the price was an
OpenGL|Performer travel bag.
o there will be simultaneous enhancements for IRIX and Linux
o develope one, Run on MIPS/IRIX and Intel/Linux
o best OpenGL performance
System requirements
o Suse, Red Hat, Caldera etc,
and the SGI Linux ProPack (set of libs and programs to get
your Linux right to run Performer (?))
o OpenGL (mesa, opengl sample, card drivers)
There is effort going on to get a platform uniform implemantation
regarding the position and content of libs and header files.
o xFree86
a question about the running with xFree86 4.0?
If it does not work then the problem is because the card vendor
has not updated yet to xFree86 4.0.
o glib 2.1.1.6
Current limitation
o Single process
no forking of CULL, DRAW, DBASE or X input
o Single pipe
because Linux is not yet supporting multiple accellerated
video cards. When it does then performer will be too.
Only on Irix
o shared memory arena
o REACT
o datapools
o cliptexture
o video channel extensions, like DVR
o fog modes
o pipeline instrumentation & statistics
o calligraphics
Porting/Running to/on Linux
o watch for 'warning messages' telling 'Not supported on Linux'
o usage of debug libs /usr/lib/Performer/Debug
o OpenGL only
o it's easy, lot of sample progs
it took allan 25 min to port perfly,
20 min used to edit the make file, find where every thing was
o Endianness
(allan we still get the story of where the term endian comes
from)
- Intel Little endian
- Mips Big endian
- Typical cases
- binary files (pfb, rgb, flt, pfi ...)
- flip the bytes in a custom fread function
see pfb loader for an example
- colors specified in single 32 bit ints
irix 0xRRGGBBAA
linux oxAABBGGRR
o OS diffs
- system calls
- memory arena
- react
- OpenGL extensions
- header files
o Making a new application
- write with Multi Process in mind (just like on Irix)
- shared memory
in Linux the pfGetSharedArena() currently returns NULL
but use it in your allocation code of pfMalloc
- OpenGL calls only in the DRAW process
- global data alloced before pfConfig()
The multi process (alfa) version for linux was demo-ed by allan.
Notice the two '_' characters in the statistics graph of perfly.
APP_CULL_DRAW
The concluding talk was from sombody from SGI professionals UK.
(I didn't pick up his name, wasn't on the starting sheet)
The talk was about the application WorldLocator.
This was used in the 28 hour broadcast of the BCC around the millenium
activities around the world. It gives a very detailed view of the earth.
It was complety made with Iris Performer.
Used 4 clip textures. Satellite/Areal foto resolution ranged from 1 km
for the globe, 1 m for part of london and 25 cm in the area of the
millenium dome. Total diskspace needed 26 Gbyte. If this included the
cloud clipmap data was not sure.
It was a multipass rendering application, not using pfShader. Giving the
following features
o specular highlight of the sun in the sea surface
o day and night effect
o city light on the dark side of the globe
o clouds
o ionosphere haze
o atmosphere 'depth cueing'
o lens flares when looking in the sun direction
and the sun is visible
postdraw callback drawing a few disks on a line ranging from the
sun position through the centre of the screen. Intensity
depending on the amount of sun visible
Closing with a demo of the application.
Better performance at the SGI booth because they have better Onyx2
hardware , Fibre Optic Disks and the new iR3 hardware.
Next where a few questions:
Simon Mills asked about Fahrenheit.
No longer developed by SGI. Now only Microsoft develops it.
This is the very short version of all the sales/manager talk that was
spoken.
The question about xFree86 4.0.
SGI will come with new boxes running Linux, a desktop workstation up to
large servers.
The other questions slipped my mind.
That's about it,
Mario Veraart
This archive was generated by hypermail 2b29 : Wed Apr 12 2000 - 13:19:11 PDT