Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!nntp-server.caltech.edu!andrey From: andrey@nntp-server.caltech.edu (Andre T. Yew) Newsgroups: comp.sys.amiga.graphics Subject: Re: Idea for a graphics board Keywords: 24 bit Message-ID: <1991May30.010621.18275@nntp-server.caltech.edu> Date: 30 May 91 01:06:21 GMT References: <1991May28.191019.13406@nntp-server.caltech.edu> Organization: California Institute of Technology Lines: 61 nygardm@nntp-server.caltech.edu (Michael T. Nygard) writes: >Here's a description of my dream graphics board >i860 processor for anti-aliasing lines, fast 3d polygon renders, Goroud & Phong >shading. (64 bit busses.) >4M memory for frame buffer & z-buffer >1024x1024x24 resolution >8 bit z-buffer Since we're talking dream graphics boards here, why don't we go all out? How about a pipelined system, a la Silicon Graphics? I guess we could have several i860's pipelined together. The first one might do the transformations (rotation, translation, scaling, figuring out the surface normals). The second pipeline could do all the lighting. The third could do clipping. The fourth perspective transformations, and the fifth just converting everything to device coordinates. Since you don't want to bog down the pipeline too much, some tasks that might be bottlenecks could be spread out over several processors. For those who are wondering, yes this sequence is shamelessly ripped out of the SGI GTX pipeline. I think that if you do it this way, the limiting factor would be how fast you could move your data onto your screen, especially since we'll have just one 860 doing the scan-conversion and Gouraud interpolation (yes, I'm interpolating colors in device coords.). Of course, to control this pipeline, each i860 would have to have some kind of input FIFO buffer that's fast enough to grab things from the previous processor and some sort of local memory for scratch space and maybe storage if we get a pipeline stall. The way the SGI GTX does the raster part of the system is to fan out to 20 Image Engines. Each engine controls 1/20th of the screen, or 64K pixels on a 1280x1024 screen. Perhaps we could have some other processor that talks well to an 860 to handle this part instead of that last i860. My guess is that we should have some processor that can address lots of memory (21 bits or more of address space, depending on what special effects you'd like to have) and can DMA very fast in and out of that memory. How about an i960CA? If you want to do some special effects, you'd have to have some computation power, too. Now, for the specs. Let's say we're doing a 1280x1024 screen and we have 20 screen processors. Let's say they're 960's, but we decide to put only 2^24 bits of memory on them (16MB). That means that each pixel would get (each 960 controls 2^16 pixels) 2^8 bits. That's 256 bits per pixel. You could divide this up in to two 24 bit buffers for double-buffering, with 8 bits per buffer for alpha channels and you have 192 bits left. How about 12 bits for a windowing system, and 24 bits for a Z-buffer. The remaining 156 bits can be used for texture maps or other special effects. I have absolutely no idea what the throughput of the pipeline would be. So there's my dream graphics board, or at least a gross caricature of it. Memory would probably be as expensive at least as the processors. I figure an upper limit of 2^25.5 bits of memory. It would be nice too to have some way of writing over the code for each stage of the pipeline so we could use it for some other things too. Perhaps we could attach ROMs to each i860 with the normal graphics code that they could copy into their own, say, SRAM whenever we initialize the pipeline for graphics. And when we want to, we could have the i860 load its programs from somewhere else so we could write our own applications for the pipeline. BTW, programming this thing would probably be very difficult. Andre -- Andre Yew andrey@through.cs.caltech.edu (131.215.131.169)