Path: utzoo!utgpu!attcan!uunet!mcvax!enea!diab!pf
From: pf@diab.se (Per Fogelstr|m)
Newsgroups: comp.arch
Subject: Sw vs. Hw BitBlit.
Summary: I will never belive Sw is faster than "Hw".
Keywords: BitBlit.
Message-ID: <399@ma.diab.se>
Date: 26 Jul 88 15:30:36 GMT
Reply-To: pf@ma.UUCP (Per Fogelstr|m)
Followup-To: comp.arch
Organization: Diab Data AB, Taby, Sweden
Lines: 46

This is my very own reflections about the recent discussion.

I have during my days worked with a few software and hardware driven
graphic systems. And i can not, from what i have learned until now
accept that a software BitBlit done by a general purpose micro (for ex
a 68K ) can be faster than a "hardware".

If we assume that the speed of the BitBlit is dependent on the memory
bandwidth, all bus cycles doing anything else than movin data is overhead.
Agree ??.  Okay, so even if a 68k is doing a "Blit" in straight code
it will consume some memory bandwidth. A micro programmed "hardware" blit
will be able to use every memory cycle for data accesses, thus having much
higher transfer rate. Correct me if i'm wrong...

I know that the Amiga has been discussed. From what i know
the Amiga has the graphics part of the main memory isolated from the rest of
the bus. This means that the Blitter in the Amiga can do a Blit without
disturbing the 68k cpu. And even if the 68k accesses the graphics memory
the blitter will still have 50% of the availible bandwidth left for its work,
because the 68k only needs the other 50%. (Hope i'm not to desinformed).

Assuming we have a fast micro (an 68030 or a NS32535) the would at least be
supported by their on chip caches. Even if the hitrate in theese caches are
as low as 50% an external hardware Blitter could use the other 50% for its
work, and the micro would run at full speed. So the cpu does not have to
wait for the memory.  

Someone pointed out that placing characters is the main work for the BitBlit.
Yes, that is correct in some systems and this is a problem in many cases.
Placing a character can take from 20micro seconds and up, and the cpu has to
wait for the blitter to be ready before placing the next character. Then 
20 microseconds is to litle for a context switch and the cpu is wasitng time
waiting. But 20-30 microseconds is at least faster than the cpu can place
the caracter anyway. And if the graphic engine is smart enough it can fetch
characters from the buffer or main memory itself and offloding the micro
until it needs some help with a special character (scrolling etc.)

And talking about scrolling ! Everyone who has seen a Sun scroll must agre
that the screen must be scrolled in less than one frame (1/70 of a second)
to make a pleasant impression. I would like to see a 68k do that with
a 1k x 1k x 8 plane display in one frame time.

An other argument i have heard is "But look at the Mac, its cpu driven and its
fast !". Well, i just have one answer to that, what is the display resolution ?

Ok, start flaming i'm ready, but beware, my blitter is fast !!