From: Benedikt Kessler (bjk++at++sgi.com)
Date: 08/25/2005 01:25:07
Hi!
> Steven Queen wrote:
>
> Also evaluating a Prism here with similar results. Performer app is only about 25%
> faster than IR3 Onyx, and with a whole lot less memory.
You should compare price/performance!
On IR your bottleneck is mostly in the geometry stage (or data transfer to the pipe); Pixel fill even with good multisampling was quite ok. The commodity graphics vendors claim much higher pixel fill, but once you also need fair quality you pixel
performance compares to an IR3 (I think) with two raster managers.
By using multiple (and still much cheaper than IR) pipes and compositors you could scale your graphics performance (or improve quality).
Sure you have much less memory on commodity graphics boards; and that memory must be shared between frame buffers, textures, display lists, vertex array objects, ... But to get good or peek performance you need to have all your data in graphics memory.
Thus it's crucial to make use of vertex array objects (or similar OpenGL constructs) and to have an eye on your graphics memory usage; for example you may look into /proc/dri/0 and 'cat umm':
free AGP = 1061814272
max AGP = 1060175872
free LFB = 108937216
max LFB = 108904448
free Inv = 134217728
max Inv = 134217728
total Inv = 134217728
total TIM = 0
If you're running out of LFB or Inv then you used up all your graphics memory and may loose performance by texture or geometry swapping.
You may also want to use the .geoa or .gopt pseudo loaders to get your data packed into vertex arrays (see pfdOptimizeGraph and pfdLoadFile_gopt manpages).
> General system is worse at multi-tasking.
> We are also having issues with Performer lossing its IRIX (InfiniteReality) functionality
> in the new releases (DPLEX and depth map shadows). Little to no response from the
> Performer team on our issues (that's really the worst part). Not a happy camper here!
>
But you also got new functionality on the other hand (vertex/pixel shaders, ...).
Performer automatically enables sync to vertical blank (and I think that's what everyone should do); thus even in FREE_RUN phase mode you could not go faster than the pfFrameRate that got set (probably 30 or 60 Hz); I assume that your 'fast' OpenGL
application didn't do that sync (as all/most of the commodity graphics drivers don't do that be defaults); so you would not compare apples with apples if one of the tests syncs but the other does not.
In order to have let the driver sync your OpenGL application with the vertical blank you can "setenv__GL_SYNC_TO_VBLANK 1"; That is what Performer does automatically unless you do a "setenv PF_SYNC_TO_VBLANK 0";
To avoid any syncing (with vblank) in Performer you "setenv__GL_SYNC_TO_VBLANK 1", set pfPhase to FREE_RUN and the pfFiledRate to 0 (when using perfly you could press Shift-F).
The Performer stats may eat up quite some time (maybe something in the rendering of the text could be improved here) so when I run 'perfly -M0 cow.obj' with just the "one line Pipe stats" I get around 210-225 Hz
Bye! Benedikt
> Dan Johnston wrote:
>
> > We have been evaluating a 16 processor Prism for that last
> > couple of weeks. We are seeing if this is the hardware to
> > replace our 16 CPU ONYX Monster.
> >
> > Using the 'gcc' compiler we get 'blazing
> > fast' OpenGL applications (mostly OpenGL based CAVE
> > applications). But any CAVE-Performer or 'raw'
> > Performer applications ran only so-so, about as fast
> > as an Octane perhaps.
> >
> > We were told that using the Intel compiler would improve
> > thinks, but unless the Performer libraries are also
> > re-compiled in a more optimized mode for this hardware,
> > most of my applications (Performer based) will not see
> > much improvement.
> >
> > Also.. We have system reliability problems (network
> > interface would freeze and console display would lock up).
> > The graphics drivers for the console are poor (geometry
> > has holes, low stereo resolution, geometry appears and
> > disappears when moving viewpoint). All this will be
> > 'fixed in the next release' but is a sad sight after all
> > the previous solid and reliable UNIX systems we used
> > to get from SGI. We can get "buggy" systems from
> > anyone - especially MicroS... - so what is the reason
> > to specify SGI???
> >
> >
> > Dan Johnston
> > National Research Council of Canada
> > London, Ontario
-- +---------------------------------+----------------------------------+ |Benedikt J. Kessler | Silicon Graphics GmbH | |Advanced Media Products | Am Hochacker 3 - Technopark | |SGI | 85630 Grasbrunn-Neukeferloh, FRG | | --- __o ,__o | | | ------_ \<,_ _-\_<, | Phone: (+49) 89 46108-366 or -0 | |----- (*)/ (*) (*)/'(*) | Fax: (+49) 89 46107-366 | +---------------------------------+----------------------------------+ |E-Mail: bjk++at++sgi.com Web (private): http://sgiweb.org/bjk | | Web: http://www.sgi.de | +--------------------------------------------------------------------+
This archive was generated by hypermail 2b29 : Thu Aug 25 2005 - 01:25:39 PDT