Re: OpenGVS Benchmark Applic

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Tue, 30 Apr 1996 12:06:00 +0100


On Apr 29, 10:29pm, Steve Baker wrote:
> Subject: Re: OpenGVS Benchmark Applic
> RE2 on the "same" database.
>
> If we take that database back to GVS, what will happen? Well, since
> the original version was optimised to death for GVS, it's likely that
> the single-CPU rendering that GVS uses will probably suffer greatly
> from the increased cull times, leaving little time left for everything
> else. Please note, this is NOT a slur on GVS - the Performer version
> uses an additional CPU, so it's not a fair test.
>
>-- End of excerpt from Steve Baker

An excellent post but I don't see how you can conclude that this test wasn't
fair. I think you've possibly come as close as you can get to a fair test for
your application by optimising for Performer and GVS and as far as I can see
the reasonable conclusion is that with Performer you can better utilise the SMP
and that on some platforms & some applications this has an impact upon
rendering performance (not exactly news). This is an area where SGI is very
strong and is often a factor in the choice of platform.

I think comparrisons of different rendering software on a specific Silicon
Graphics platform can be usefull provided the benchmark is tunned for each, up
to date and you bear in mind that speed isn't the only performance factor. I'm
thinking mainly of features here but ease of use is important to a broader
community, as are portability and open standards.

I would also suggest that as more vendors adopt the OpenGL rendering
specification that cross platform benchmarks will become more usefull although
this is open to gross abuse(and ignorance), and many will never adopt OpenGL.
In any case, many of your objections to this approach would still remain valid.

Rgds,
Angus.

-- 
Angus Dorbie,
The Reality Centre,
Silicon Graphics Ltd, UK
dorbie++at++reading.sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:49 PDT

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