From: Dale_Adams@gateway.qm.apple.com (Dale Adams)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Benchmarks results for video writes
Date: 12 Jan 93 00:20:49 GMT
Organization: Apple Computer Inc.

In article <1993Jan11.203605.2932@nntp.hut.fi> jmunkki@vipunen.hut.fi 
(Juri Munkki) writes:
> >The speed depends on several factors :
> >
> >1) the speed of the CPU running the program
> >2) the speed of the link between the processor and the video memory
> >3) the conflicts with screen refreshing
> 
> You have completely forgotten graphics accelerators. Simple video
> access times do not give you the whole picture.

It really depends on the particular graphics operation you're performing.  
If you're doing an offscreen-to-onscreen copy (without any specialized 
GWorld memory), then the typical crop of Mac graphics accelerators won't 
help you at all.   In this case, the three factors above are probably the 
significant one (although #3 is really included in #2 - bandwidth into 
video RAM is affected by screen refreshes).  An animation may well run
faster on a machine with direct processor access to video memory than on
a machine with a graphics accelerator on NuBus.

> >The (partial) results show that 2) is the most important point,
> >while 1) and 3) have some influence. It is remarquable that a
> >Macintosh LC is faster than a Macintosh IIfx (this explains why
> >Apple can demonstrate excellent QuickTime on a Mac LC on the 12"
> >color display).
> 
> You give no indication of what your benchmark actually does. Did
> you write directly to screen memory or did you use quickdraw routines?
> I suspect that you just write directly to the screen in a very tight
> loop. If you do this, you can just forget about any improvements from
> the accelerated video cards. Also, the code will fit nicely into the
> tiny instruction cache on the 68020.

Yes, this would be good to know.  What exactly does the benchmark do?  
Note, however, that intelligent coding of a graphics routine would make 
every attempt to fit the code into the cache of the processor it was 
running on.  I've been told by one of the QuickTime authors that they 
tried very hard to make the core video codec routines fit in an '020/'030 
instruction cache.  Things are much easier with an '040, of course.  :-)

> Furthermore, if you write a pixel at a time, you will not see the
> degrading effects of running with a 16 bit data bus.

True.  Again, it all depends on the nature of the graphics routine being 
performed.   Drawing lines would not be much affected by this, while an 
operation like scrolling would be.

> >bits/pix  1       2       4       8       16      32
> >(Mb/s)   6.64    5.53    3.49                          si built-in
> >(Mb/s)   4.58    4.58    4.58    4.19     4.19    4.34 fx Supermac 8/24 
PDQ
> >(Mb/s)   4.69    4.69    4.69    4.69                  LC built-in
> >(Mb/s)   8.30    7.38    6.64                          ci built-in
> 
> Real life experience tells me that the fx should be clearly faster than
> any of the others. Yet you get the lowest performance on that machine.
> I think this reveals a lot about your benchmark.

Actually, granting that factor #2 is the dominant one (which was stated by 
the benchmark author and is certainly true for some types of graphics 
operations), then the above numbers make a lot of sense.  All the Macs 
listed have video memory located directly on the processor bus except for 
the IIfx.  The IIfx must go through the asynchronous NuBus interface and 
will therefore incur the synchronization delays that entails.  Bandwidth 
into NuBus video memory is probably on the order of 4-5 Mbytes/sec. on a 
IIfx.  In addition, I've seen a number of cases where a IIci, with it's 
direct access into video RAM, is faster than a IIfx.  It all really 
depends on what type of graphics operations you're doing.

- Dale Adams
  Apple Computer, Inc.
Newsgroups: comp.sys.mac.advocacy