jrg@Apple.COM (John R. Galloway) (04/14/89)
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 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? apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!
rick@sbcs.sunysb.edu (Rick Spanbauer) (04/15/89)
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
joel@pandora.pa.dec.com (Joel McCormack) (04/15/89)
I hope that no one at DEC has claimed that the DECStation 3100 wouldn't be faster with a special graphics engine. Having done the code for the color frame buffer, I'll be the first to admit that extra hardware could help. The main advantages of the frame buffer are: 1. You get performance that is quite good (actually downright amazing considering that it's all going through an X server). Further, this performance will improve automatically as you use faster CPU chips and memory. 2. It costs nothing other than the RAMs. 3. It is a lot more flexible than commiting to a hardware accelerator. I've improved performance in serveral areas, and all it takes to get it into your hands is another release of Ultrix. 4. It is faster to get a frame buffer up and running than designing a new chip would have been. - Joel McCormack (decwrl!joel, joel@decwrl.dec.com)
tc@diablo.amd.com (Tom Crawford) (04/16/89)
In article <2565@sbcs.sunysb.edu> rick@sbcs.sunysb.edu (Rick Spanbauer) writes: > 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 > They also have a set of graphics primitives (assembly language, callable from "C") that are available *now* for the 29000. Check it out. Tom Crawford (408) 749-5100
rec@dg.dg.com (Robert Cousins) (04/17/89)
In article <28930@apple.Apple.COM> jrg@Apple.COM (John R. Galloway) writes: > 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? > >apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca > >These are my views, NOT Apple's, I am a GUEST here, not an employee!! Yes, we choose to use graphics coprocessors on our AViiON line of workstations for several reasons: 1. Lawrence's Law: There are only two ways to speed up a computer: build it out of faster parts or do more than one thing at a time. A coprocessor allows you to do more than one thing at a time. 2. Sure the 88000 is fast and can do graphics operations very quickly (faster than most graphics coprocessors in fact). However, more and more workstation applications are of the form "compute, draw, compute, draw . . . ." where the parallelism gain is substantial if draw and compute can be overlapped. 3. Most previous graphics architectures assume relatively weak CPUs and relatively more powerful graphics hardware or the extreme opposite of relatively powerful CPUs and totally brain damaged graphics hardware (dumb frame buffer). The newer, faster CPUs like the 88100 make intermediate balancing easy. 4. Cost. A proper choice of graphics subsystems allows not only the cost to be reduced but also the power and space -- all of which has impact on the retail cost. I think it safe to say that we did a pretty good job. There aren't any machines that I know of that can match the AViiON line in power (CPU or graphics) in the price range. Robert Cousins Department Manager, Workstation Development, Data General Corporation Speaking for myself alone.
mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel) (04/19/89)
In article <130@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >various nice things about his workstation. > >Robert Cousins >Department Manager, >Workstation Development, >Data General Corporation > >Speaking for myself alone. I apologize for taking up net space, but I've been trying to send mail to you at both "dg.dg.com" and "dg.com" and neither works for me. Could you try to send me your numerical address or another path? I want to ask some questions about your company's workstation. THanks, matt kennel mbkennel@phoenix.princeton.edu
jrg@Apple.COM (John R. Galloway) (04/19/89)
In article <130@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >In article <28930@apple.Apple.COM> jrg@Apple.COM (John R. Galloway) writes: >> 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? >> >Yes, we choose to use graphics coprocessors on our AViiON line of workstations >for several reasons: ..parallel operations and price/performance cited, but no data given... > >Department Manager, >Workstation Development, >Data General Corporation >Robert Cousins Could you describe what operations the NEC and gate array perform? What is the degree of overlap, overhaed of the synchroniztion, etc. i.e. tell us how it works and give some data. thanks! (does AViiON have some neumonic significance or something? (i.e. the case differnece) apple!jrg John R. Galloway, Jr. contract programmer, San Jose, Ca These are my views, NOT Apple's, I am a GUEST here, not an employee!!