chris@spock (Chris Ott) (07/25/88)
henry@utzoo.uucp (Henry Spencer) writes: > A good implementation of BitBlt, > whether in software *or* hardware, will run the memory flat out, leaving > nothing for "servicing other processes". (Caches help a lot on instruction > fetches, but data has this annoying tendency to require real memory fetches.) > If your CPU is sitting there waiting for memory, it might as well be doing > the BitBlt itself. Why assume that the graphics memory and the CPU memory are the same? The best thing would be to have seperate graphics and program memory, where the only time the CPU has to compete with the graphics chip is when it is actually accessing graphics memory. If you used a seperate graphics processor, the CPU would also be able to do something else while it is waiting for the graphics operation to finish without having to worry about competition for memory bandwidth. This may not be a big deal when you're working on a micro, but it is when you're working on something like a Sun and you're being billed for how much CPU time you use. In this case, it would be much better to use a seperate BitBlt chip, since a 32 bit BitBlt chip is going to be much cheaper than a 32 bit microprocessor. > Note that some of the earlier Suns had quite a bit of hardware BitBlt > assist, and the newer ones don't. Sun learned. Commodore will, someday. I wouldn't be so sure. Where I work, we have both IRISes and Suns. The Suns have software graphics and the IRISes have hardware graphics. On them, we are trying to plot color contours of a 65x338 array, using a polygon for each element in the array. On the IRISes, this takes about 2 or 3 seconds. On the Suns, the same plot (with the same program) takes about 2 or 3 _minutes_. Big difference. Also, remember that Sun _does_ supply a graphics board, if you want to pay extra for it. It doesn't appear that Sun really "learned" anything except how raise the price of their machines. As for character operations, the IRIS is faster again. On the Suns, I have no problem using ^S and ^Q. If I type ^S to stop output to the screen, and then type ^Q and ^S again as fast as I can, the Sun can scroll about 10 or 20 lines before it stops. On the IRISes ^S and ^Q are basically useless. At least a screen and a half (about 40 lines) scrolls past before the output stops again. Sun scrolling speed is _greatly_ affected by how heavily the system is being used. IRIS scrolling speed isn't. Finally, remember, the Suns (at least the 3/280) is running a 25Mhz 68020, while the IRIS is only running a 16Mhz 68020. If the IRISes were running at 25Mhz, like the Suns, they'd be even faster yet. ------------------------------------------------------------------------------- Chris Ott Internet: chris@spock.ame.arizona.edu Computational Fluid UUCP: {allegra,cmcl2,hao!noao}!arizona!amethyst! Mechanics Lab spock!chris University of Arizona -------------------------------------------------------------------------------
henry@utzoo.uucp (Henry Spencer) (07/26/88)
In article <789@amethyst.ma.arizona.edu> chris@spock (Chris Ott) writes: > Why assume that the graphics memory and the CPU memory are the same? ... Because I thought we were talking about low-end systems. (Okay, I admit, I know of low-end systems that have separate graphics memories, but one should think twice about the cost-effectiveness.) >... a 32 bit BitBlt >chip is going to be much cheaper than a 32 bit microprocessor. Oh? Why? (I can see a simple BitBlt chip being cheaper than a bloated, baroque 32-bit micro. But cheaper than a simple 32-bit micro? Why?) > I wouldn't be so sure. Where I work, we have both IRISes and Suns. The >Suns have software graphics and the IRISes have hardware graphics. [The >Irises are faster for polygon graphics.] Believe me, I know this; we have an Iris too. Have you *priced* the difference, though? Also, I was talking BitBlt, not polygon graphics; they are *not* the same thing. >...remember that Sun _does_ supply a graphics >board, if you want to pay extra for it... Correct me if I'm wrong, but I believe that graphics board is only for their color display subsystem, and (like the Iris hardware) specializes in polygon graphics. > Finally, remember, the Suns (at least the 3/280) is running a 25Mhz >68020, while the IRIS is only running a 16Mhz 68020. If the IRISes were >running at 25Mhz, like the Suns, they'd be even faster yet. For the price of the Iris graphics hardware, you could do a lot more to a 68020 than just boost the clock speed a few MHz. -- MSDOS is not dead, it just | Henry Spencer at U of Toronto Zoology smells that way. | uunet!mnetor!utzoo!henry henry@zoo.toronto.edu
shenkin@cubsun.BIO.COLUMBIA.EDU (Peter Shenkin) (07/27/88)
In article <1988Jul26.145106.5459@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <789@amethyst.ma.arizona.edu> chris@spock (Chris Ott) writes: >> I wouldn't be so sure. Where I work, we have both IRISes and Suns. The >>Suns have software graphics and the IRISes have hardware graphics. [The >>Irises are faster for polygon graphics.] >Believe me, I know this; we have an Iris too. Have you *priced* the >difference, though? .... >...For the price of the Iris graphics hardware, you could do a lot more to >a 68020 than just boost the clock speed a few MHz. OK, if you're comparing Sun-3's with Iris 3130's. But let's look at Sun-4's and Iris 4D machines (based on the MIPS chip); both lines start around $60k, I believe, but from what I've heard, the low-end 4D's are excellent scalar machines, giving about 7 mips, and you get this great graphics hardware to boot -- for free, so to speak. Caveat: I have experience with neither machine. Obviously, the folks I know who've been using 4D's have been very impressed. The comparison with Sun-4's comes from them. Contrary opinions welcomed! -- ******************************************************************************* Peter S. Shenkin, Department of Biological Sciences, Columbia University, New York, NY 10027 Tel: (212) 280-5517 (work); (212) 829-5363 (home) shenkin@cubsun.bio.columbia.edu shenkin%cubsun.bio.columbia.edu@cuvmb.BITNET