Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!convex!swarren From: swarren@convex.com (Steve Warren) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Blitter vs. 040 (was: Computer Architecture question Message-ID: <1991May20.163925.8778@convex.com> Date: 20 May 91 16:39:25 GMT References: <1991May18.104457.28023@sugar.hackercorp.com> <1991May19.124802.19879@sugar.hackercorp.com> Sender: usenet@convex.com (news access account) Organization: CONVEX Computer Corporation, Richardson, Tx., USA Lines: 68 Nntp-Posting-Host: neptune.convex.com In article <1991May19.124802.19879@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article melling@cs.psu.edu (Michael D Mellinger) writes: >> Would a blitter in the NeXT be scrolling as fast as it can? It can >> only move data 16 bits at a time, correct? > >My blitter moves 32 bits at a time. I have a 3000. > Hey, Peter, the blitter still moves 16 bits at a time; it just has a 32-bit port for the '030. But to answer Mike's question, unless he can show otherwise I have to assume that a blitter would scroll faster than a 68040 could do it in the NeXT. Mike, you still have failed to recognize this simple fact which everyone has been trying to get through to you: that 68040 is not an advantage for graphic manipulation, because the limiting factor is the interface into the screen buffer. It doen't matter that your fire-hydrant can pump out a million gallons per minute, if it has to fill up your swimming pool through a garden hose. In that case you are just as well off to use the faucet in your back yard, since it can put just as much water through a garden hose as a fire hydrant can. The biggest advantage of a blitter is that the blitter is able to put all of the available bandwidth in your display to productive use, because it's design was tuned to access this bus the most efficiently. It has no other tasks to perform, so it is always available to do graphics manipulations. The blitter is able to weave in and out of other accesses in order to get its job done. This allows maximum utilization of available bandwidth. A general- purpose processor is not good at this. By the time you could get the attention of the 68040 (via an interrupt) the available access would have gone past, because screen updates cannot wait. The other alternative is to just force the 68040 to sit on the display bus and wait-state it until an available cycle comes open. In that case your 5-30 mips (whatever) 68040 is dropped down to the level of a .1-.5 mips blitter. It's capacity is totally limited by the capacity of the interface into the buffer. If it is wait-stating on the bus, then it is not doing anything at all *except* waiting. *And*it*will*do*a*lot*of*waiting*. No matter how fast your processor is, dedicated smart I/O devices with DMA are always more efficient. Your processor has to down-shift into granny-gear while it is doing I/O jobs that dedicated devices could do better. While in this mode, its performance is significantly lower than its "on-paper" capacity. The percentage of time that your processor spends doing tasks like this can be directly subtracted from the total performance capacity of the procesor. That is, a 20 mips processor that spends half its time doing I/O is really a 10 mips processor, as far as the user is concerned. The irony is that the I/O being done for 50% of its time is not really 10 mips worth of I/O; it is probably less than 1 mip worth of I/O. But because the processor can go no faster than the I/O it is talking to, it loses 50% of its wall-clock time while only doing a small part of its total work load. That is why this approach is so inefficient, and that is why a 68040 Amiga is going to significantly outperform the NeXT. The Amiga lets the main processor do what it does best, and off-loads the inefficient I/O jobs to simple dedicated processors. So with the Amiga all of your processor performance is available for the real work. -- _. --Steve ._||__ Warren v\ *| V