🚀 go-pugleaf

In article <1032@mpirbn.UUCP> p554mve@mpirbn.UUCP (Michael van Elst) writes:
[stuff deleted]

>Howl, howl. This is a tight point of view ignoring that blitter operation
>is _parallel_ to cpu operation.
>
>The blitter can fill screens fast enough. You can't go faster than the
>display refresh rate. There's absolutely NO need to do operations with
>the CPU that can be done with the blitter.

  I've done extensive benchmarks/speed tests, and the parallelism of
the blitter does not make up for its slow speed relative to a fast
32 bit processor (020/030).  Realize that in the case of filling a polygon
or copying bitplane data, the blitter is only running parallel on the *last*
blit. Thus for a four bitplane blit, for the first three blits I must WaitBlit()
before the next blit. 
  The blitter cannot *render* screens fast enough.  Nor can the processor.
For a complex scene, 30hz (stereo 3D) would be ideal, but we just don't
have the horsepower available and thus the refresh rate issue becomes moot.
But, when using the 32 bit processor we can render up to *three* times
as many polygons as the blitter.  While it's true that you can never
exceed the scan rate and the +/- 16.6ms lag time, there are techniques
to eliminate waiting for the display, ever.
  Finally, on the 3000, chip ram is now 32 bits wide, and we can
now take advantage of 32 bit writes in half the time. The blitter
is still working with 16 bit writes.  I wrote a simple benchmark
that just did a bunch of move.l's to chip ram. I compared a 28mhz
GVP to a 25mhz 3000. The 3000 was twice as fast.  My scan conversion
code runs over 30% faster on the 3000 than the GVP, over three times
faster than the blitter.  Until we see a 34020 or equivalent for the Amiga,
we can dust the blitter with the 32 bit processor for polygon fills.



  John