Remi Arnaud (remi++at++asd.sgi.com)
Fri, 16 Aug 1996 11:07:06 -0700
Do you use Performer ?
Even if you don't, Performance related questions have a e-mail list:
post your message in: info-performer++at++sgi.com
And send a request to be part of the mailing list in:
info-performer-request++at++sgi.com
Anyway, I'll try to help you from there:
Jeffry J. Brickley wrote:
>
> I am trying to get the fastest possible update with the maximum "look" for a
> major operation in one week! I don't have time to try every possible
> combination of ways of doing texturing on an SGI to see which is best for
> Infinite Reality, so if anyone can help me out I'd REALLY appreciate it!
> First of all our hardware specs:
> Onyx with Infinite Reality
> 16 R10000 processors
> 4 RM6 Raster Managers (64Meg each) per pipe
> 2 Pipes (running dual channel, i.e. 4 outputs)
> Second what I have seen with performer 2.1 and OpenGL:
> 48 MB of 3color 1Kx1K textures map at 20hz update with 2 polygons
> per texture.... (great wonderful for our "map" display)
> 36 MB of 1color grey scale textures (1Kx1K) at 2hz with less than 1000
> polygons per texture of which only 5MB of texture is visible, the
> others have be culled in from a higher level of detail.
> What can I do to improve performance?
Your machine have 64MBytes of texture memory, regardless of the number
of Raster Managers. More raster managers give you more pixel (screen)
memory and bandwith, but no more texture. All the RMs have a copy of the
texture memory, so they can work in parallel on different pixels.
If you try to use more than the texture memory capacity, the machine
has to use it's main memory to continuously swap textures. This is THE
major performance issue.
If your database contains more than 64MBytes of memory, you want to do
texture paging. Also, you could use ClipMapping (a unique feature
available on iR with Performer 2.1, and let the system page for you HUGE
textures)
> Are we limited to one RM6 at a time in use and the rest as texture
> "storage"?
Now you know ;-)
> If I spend the effort to reduce polygons will it help? I have
> displayed more polygons at fewer textures while mainting 20hz update rate.
The next performance issue, is the number of texture bind you have in a
Frame. The graphic pipeline has to change it's state each time. Imagine
you have 10 objects of 10 polygones. Each object have one texture.
If you draw 1 polygon of an object, then switch to the other object ...
, you will be doing 100 texture binding. You really want to sort by
texture binding.
Of course, if you use Performer, this State management is done for you,
but reducing the number of images helps a lot (sharing all the side of
an object (eg building) in the same image)
> Are my greyscale textures being used as 3byte (or 4byte with alpha)
> internally that I cannot see?
Performer tells you the % of the texture memory you use. As far as you
stay below 100%, it doesn't matter.
And the answer to your question is no, unless your software force it.
> Why are my culled textures affecting the overhead performance, am I
> wrong in assuming they are not being textured if the LOD is not visible?
Texture cannot be culled. They are in the texture memory, or they are
not loaded, and this is not a real-time process.
However, polygons are culled in Performer.
> What is the "fastest" texturing methods of all of the variations of
> minfilter(point,linear, bilinear, mipmap,etc.) , magfilter, and mode
> (modulate, decal, blend). I have assumed that mipmapping is best as all of
> the calculations are done ahead of time at a cost of 1/3 more texture memory
> (is my calculation for overhead wrong?)
There are some differences, but IR is optimised for trilinear
mip-mapping. If all the polygons in your database use this technique,
Infinite Reality gives you more than 15000 polygons at 60 Hz
> I have used textures at each LOD, thinking that if I reduce "texture"
> displayed, it will increase performance.... Have I assumed incorrectly?
I don't understand that point. By LOD do you mean Texture Level, or
Object Level of detail (less polygons) ?
> 4 1Kx1K 1 color textures on LOD 2&3 with 3000 & 6000 polygons respectively for
> up close views, these display fast and efficiently near as the "eye" is near
> the terrain, very impressive, very fast!
So you mean LOD = Object level of detail. It seems to mee that you
would like to use the Dynamic Terrain feature in Performer 2.1 ??
Did you ever see a ClipMapping + Dynamic terrain demo ?
> ===========
> | | |
> |----|----|
> | | |
> ===========
> 1 1Kx1K 1 color texture on LOD 1 for far away views (I assumed this was best).
>
> In our complete Database there are 8 of these detailed cells, but I got to the
> 5th and the rate dropped to 2hz directly from 20hz as if we crossed a boundry
> that we need to stay away from....
It must be the texture memory capacity.
> Does any one have real specs on IR systems of polygons ++at++ 20hz, colored
> polygons ++at++20hz, textured polygons ++at++ 20hz, colored and textured polygons ++at++
> 20hz? If so, what texturing methods are used for benchmark? OpenGL only?
> Performer 2.1?
>
It is application dependent, but in your case (big meshes sharing the
same texture), you should easily get 45000 to 50000 polygons at 20 Hz.
The last limitation of the graphic is the Pixel Fill Rate.
Having 4 Raster Managers in your system, you can have more that 600 M
Pixels touched per second. (per pipe)
Giving a 2x 1280x1024 screen, and a 20 Hz refresh rate, you can
calculate that each pixel can be touch 12 times per frame. So this
limitation should not be a problem for you, unless you really have more
than 12 screen size objects drawned each frame.
Best Regards
-- Remi
o o Remi ARNAUD - Silicon Graphics, Performer, Advanced Systems Dev
o o
o o Mail Stop 590 - 2011 N. Shoreline Boulevard, Mountain View,
CA94043 o o
o o Email: remi++at++asd.sgi.com - Tel: (415) 933 6208 - Fax: (415) 965
2658 o o
PERFORMER :
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:22 PDT