Re: MISC video spec (640x480 ?)

[Penio Penev <penev@xxxxxxx>]

On Sat, 22 Mar 1997, Jeff Fox wrote:

> The number of color is also very limited, but that is a separate issue.
> P21 only generates 15 colors.  There are four bits to designate color,
> but there is no difference between dark black and bright black (intensity
> makes no difference if all the primary colors are 0).  One can get
> an increase in apparent color resolution by dithering, but this decreases
> spatial resolution and as noted above can lead to pixel flicker.

One can get increased color resolution by dithering in time, which
shouldn't be difficult, and shouldn't be perceived as flicker.  For
example, in one pauses a perfectly good rental movie, one sees _a lot_ of
noise, which is averaged out by the human visual system.  It is trivial do
do the experiment on P21/i21 (I guess i21j), and it would be interesting
to see what happens.  Of course, time averaging two consecutive frames
means twice the memory instead of one bit more per pixel, but no
additional bandwidth, or some dynamic mechanism for updating the frame, at
the expense of twice the bandwidth. 


> A resolution of 384x482 on P21 ( and F21 ) requires aout 62K words
> of memory to hold both the pixels and the video framing instructions.
> Producing 640x480 would require almost twice as much memory and consume
> twice as much memory bandwidth.  Resolutions up through 1024x768 should
> be doable.  Since there is no color modulation the RGB video from F21
> should be sharp clean and vivid.  It is still however low color resolution.

The same game can be played here -- flicking two frames so that the eye
averages them. 

> You will note that if the design were changed to use more bits per pixel
> that the memory size bandwidth requirements increase.  100% of DRAM would
> hold 1024x1024 pixels, but no framing instructions, so it would not be
> doable to provide all memory to video, the cpu needs a little. :-)

> However one should also note that there is also an analog coprocessor
> on F21 separate from the video coprocessor, and that F21 has a network
> coprocessor for multiprocessing.  
> 
> The F21 analog coprocessor is fast enought to generate video signals, and
> with very little hardware and a little software F21 could also generate
> a video signal from the analog coprocessor.  I have not actually designed
> such hardware or code so I don't really know what restrictions apply.
> However the signal is a 6 bit signal so one might be able to get 64 shades
> of grey or colors depending on the design.

> There is also the potential to generate a single video signal using more than
> one F21 at the same time.  It may not be the most efficient or easy way 
> to generate video, but in a system with a bunch of F21 connected together
> you could have one virtual monitor (like in the Apple OS) with many
> screens, and you could have several F21 generating video to one screen.

Of course, if the main problem at high resolution is the memory bandwidth,
putting three busses instead of one is exactly the solution.

> If you 6 bit analog output on each RGB line you could get 256k colors in
> super vga resolutions.  

3x6=18 bits of color, 256k colors.  A somewhat common mode in the PC world
is 16 bits/pixel, with 5 bits/color and one either wasted, or devoted to
the green.  6 bits/color is better than that. 

> We also plan to experiment with interfacing other other video output
> chipsets and devices.  Image rendering inherently parallel and with scalable 
> computing power it may be useful to compute very high resolution
> images that well beyond the range of video that can be generated
> by the F21 chips themselves.

Interfacing to other video output chipsets and devices?  Are we talking
SGI here :-)

Say, put a couple of F21s (2 in.sq / CPU+memory module) on an XIO board
that fits into an OCTANE/Origin/Onyx and has 800 MB/sec bandwidth.  These
boards are 25" x 17" = 425 sq.in, so one could fit, say 200 F21 modules
there and connect them to the "video chipset and device" :-)  Or to
another XIO card with 4 ATM OC3 (4x150=600 MBytes/sec) ports.  The R10K in
the box will only do the billing :-)


--
Penio Penev <Penev@pisa.Rockefeller.edu> 1-212-327-7423