🚀 go-pugleaf

In article <28930@apple.Apple.COM>, jrg@Apple.COM (John R. Galloway) writes:
> There has been considerable discussion already on the pros & cons of the
> approach used by Digital on the DECStation 3100 of using the cpu for all
> graphics tasks (basically the idea is that the cpu is so fast that graphics
> operations are limited by memory bandwidth, so graphics engines will not

	If your path into the frame buffer is only 32 bits, then yes, it
	is easy to saturate the FB.  It doesn't have to be this way.  If
	you've the bucks, widen the path.  Both the National RGP and AMD QPDM
	have paths wider than 32 bits into 8 bit frame buffers.  The former
	can achieve blit rates of 80 mPixel/sec by using page mode cycling
	into 8*16 = 128 bit wide path into the FB.  For the ulimate performance
	put the blitter op unit on the memory chip itself, and get even
	faster.  Recent TI vram, I think, does this.

> improve graphics performance, apologies to DEC if I am oversimplifing)).
>   Now I see there is another example.  The Data General Maverick 88000 based
> workstation uses an NEC 72120 (whatever that is) for mono and a custom
> gate array (whatever_that_is**2) for color.  Any DG engineers out there who
> would like to discuss why they chose to do so?  

	The other interesting question is how well suited to graphics
	a particular RISC is.  The 29000 for instance has a nice load/store
	multiple insns + large register set that can be easily matched
	to the page mode cycling features of dram/vram.  You can:

		LOADM	128 pixels -> registers @ 40 nS/4 pixels
		operate on pixels in registers
		STOREM 	128 pixels -> memory @ 40 nS/4 pixels

	and achieve some fairly decent update rates even with packed pixel
	format FB + 32 bit paths.  With extra logic, eg R3000's, etc can do
	this too.

> apple!jrg	John R. Galloway, Jr.       contract programmer, San Jose, Ca

					Rick Spanbauer
					SUNY/Stony Brook