Historical Overview 1960 First random scanned display available 1 Interactive Graphical Systems 1964 A few applications using computer graphics ($100.000) 100 Fall 2002 1968 Phosphor storage tubes increasingly available ($5000) 1000 1978 Raster scanned displays become increasingly popular 100.000 1984 First PC with graphical user interface (Macintosh) 1000.000 Image Generators and Displays Stefan Seipel 1994 Graphical user interfaces replaces increasingly text interface 50.000.000 1999 Almost no computer available without GUI 200.000.000 (Source: E.Bengtsson, Uppsala University) Random scan display Random scan display - computer control • based on phosphor storage tube • computer keeps a list of graphical primitives • cathode ray is controlled arbitrarily in XY direction • analog control of ray implemented in electronic circuits • computer issues rendering and parameters • sets of vector primitives available (points, lines ) • very little memory required to store display list • very smooth lines / high resolution • no management of graphics buffer required • line drawing only • no filled surfaces • display/engine and computer strictly separated • no block transfers • limited time frame to draw graphics • up to 100.000 short vectors per refresh cycle Raster scan display Raster scan display - computer control • based on TV technology - short glowing phosphors • computer manipulates values in the frame buffer • screen is scanned in a line-by-line order • discrete frame buffer matrix -> rasterization • pixels within a line are switched on/off while line is scanned • arbitrary graphical objects can theoretically been displayed • two-dimensional memory matrix (frame buffer) contains pixel value • need for rasterization algorithms • filled areas can be drawn • graphical primitives must be computed • screen must be refreshed in short intervals • host computer calculates and accesses frame-buffer • memory must be read out -> video signal must be generated Frame buffer readout - RAMDAC Simple Raster Scan Display Architecture Frame buffer RAM (random access memory) CPU Video Controller other periphery create video DAC signal host memory memory (digital to analog converter) write read System Bus (frame buffer operations) • readout of 1280x1024 pixels at 60 Hz -> memory access time 12.7 nanoseconds ! System Video Video Monitor • “normal” RAM have an average access time of 60ns Memory Memory Controller • special purpose frame buffer required • must allow for simultaneous read and write operations More or less typical configuration with common graphics cards Typical frame buffer operations: 2D graphics subsystem CPU other periphery 2D - Graphics operations • BitBlt (bit block transfer) System Bus •Draw Pixel Frame buffer operations are a heavy burden for (2D graphical primitives) •Draw Line a single CPU system ! •Draw Text System Raster Video Monitor Memory Engine Controller • Fill Area Frame (color) Buffer 2D graphics subsystem Color buffer standards (common resolutions) Memory requirements and signal bandwidths Spatial resolutions: CGA - 320x200 Spatial Resolution SXGA 1280x1024 EGA - 640x350 Color Resolution True color 24 bit VGA - 640x480 SVGA - 800x600 Screen Refresh 72 Hz XGA - 1024x768 SXGA - 1280x1024 or 1600x1280 Video Memory Requirement : 1280*1024*24 bit = 3.75 Mbyte (1.3Mio pixel) HDTV - 1900x1200 ATC - 2000 x 2000 Human eye - 10.000 x 10.000 (not evenly distributed) Video readout : 94 Mio./pixel per sec. Color resolutions: Memory readout : 226 Mio. bits per sec. ! palletized - 256 colors lookup-table (8 bit/pixel) grayscale - 256 shades (8 bit /pixel) -> very special memory readout required grayscale - 4096 shades (12 bit /pixel) e.g. in medical apps. Hi color - 5:5:5 RGB, or 5:6:5 RGB (15 or 16 bit/pixel) (e.g. 240 MHz RAMDAC) true color - 8:8:8 RGB (24 bit/pixel) true color - 8:8:8:8 RGBA (32 bit/pixel) The standard 3D graphics pipeline Modeling Viewing Display Rasteri- 3D graphics adds another dimension Transfor- Lightning Transfor- Clipping Projection List zation mation mation Traversal 2D color buffer only is not sufficient Geometric processing Rasterization - thousands of flops - operates on pixels (framebuffer) - vertex transform - millions of iops - normal transforms - alpha compares - lightning calculation - depth buffer test - stencil test - alpha arithmetic - texture addressing Features of 3D image generators Features of 3D image generators Geometric processing (per vertex operations): Rasterization (per pixel operations): One or several raster engines feature: • one or several floating point geometry engines • discrete line drawing and polygon fill • perform matrix and vector operations • z-Buffer test (depth buffer test) • z-Buffer blending (fog) hardware supported graphics operations: • transformation of vertices • blending with alpha-channel (transparency) • rotation of vectors • color interpolation (e.g. Gouraud shading) • normalization of vectors (after scale of object) • texel addressing • calculation of lightning • tri/bilinear interpolation of textures • projection & clipping • anti-aliasing of edges • stencil test Advanced 3D graphics subsystem Buffers configuration example (3D system) double buffer CPU (front and back) other periphery accumulation buffer 8 b System Bus depth buffer 24 / 32 bit alpha buffer 8 bit blue-color buffer 8 bit green-color buffer 8 bit red-color buffer 8 bit Geometry Raster Video System Monitor Memory Processor(s) Engine(s) Controller stencil and/or overlay buffer 8 bit Frame Buffer(s) Local Memory Other Buffers (caches, textures) (Stencil,Depth,Alpha…) Memory required per pixel: 2*24+8+8+32+8 = 128 bit = 16 byte Graphics subsystem For a resolution of 1280x1024 -> 20 MB frame buffer Buffers configuration example (3D stereo system) Depth-Buffer Aliasing left right Fixed number of bits in the z-Buffer limits front resolution of the scene depth Quad- accumulation buffer 8 bit buffer Example: depth buffer 24 / 32 bit 16 bit depth buffer allows only 65536 discrete steps in depth back alpha buffer 8 bit blue-color buffer 8 bit green-color buffer 8 bit Arithmetical rounding operation red-color buffer 8 bit of floating point depth values causes ambiguous z-values ! stencil and/or overlay buffer 8 bit Visual artifacts in rendering of objects which are very close to Memory required per pixel: 4*24+8+8+32+8 = 176 bit = 22 byte each other (see picture) For a resolution of 1280x1024 -> 27,5 MB frame buffer Performance parameters – History (1999) Performance parameters - What do they say ? Pixel Fillrate: Problem: • refers to rasterization performance • number of shaded/textured/buffered pixels per second • stated performance values are often only achieved under specific circumstances • common: 5-40 million/sec. (low and medium cost game accelerators) • often these values refer to the most simple rendering modes (no shading, no z-buffer) • quite good: 100 million/sec. (graphics workstations) • performance is often achieved with native implementations • high end: 500-2000 million/sec. (e.g. SGI top of the line) • quality of driver implementation is essential Geometry Performance: • comparability is a tricky issue, since various new technical features • refers to throughput of graphical primitives • number of 3D shaded triangles/sec. (of certain size e.g. 25 pixel) Therefore: • number of 3D shaded lines/sec. (of certain length e.g. 10 pixels) • don´t trust vendor supplied specifications ! • common: <0.5 million triangles/sec. (low cost game accelerators) • if you are lucky, you reach 10%-20% of the stated performance ! • quite good: <1-2 million triangles/sec. (graphics workstations) • graphics sub-systems should be tried before bought ! • high end: <50 million/sec. (e.g. SGI Octane) • in the target system (depending largely on CPU configuration) • using your application (depending on typical graphics operations) Nowadays (2002) performance doubled with ten even on PC hardware The gap between professional systems and consumer products is closing • Always check : is there driver support ? are there drivers at all ? Bottlenecks in 3D graphics systems Example bottleneck evaluation Geometry bound systems User requirements for a flight simulation: - too many polygons in the scene • terrain model 1000 textured polygons, will fill most of the screen background • airplane model 5000 polygons, average size 200 pixels - too complex lightning calculation • for quality reasons, rendering should appear in SXGA resolution - too complex model transformations • frame-rate >40/sec. Fill bound systems There is a graphics subsystem available: - too big areas to fill (number of pixels per polygon) • 60 Mio. textured, lit, shaded pixels/sec. - too many large polygons • 2.000.000 triangles/sec. (25 pixels) - high overdraw ratio • cost: 30.000 SEK - too many textures in scene - too complex alpha arithmetic (blending, fog) Is it advisable to buy this graphics subsystem ? Fill bound! • (1280x1024+5000x200)x40 = 92.428.800 pixels/sec. Depends on your application and graphics system • (1000+5000)x2x40 = 480.000 triangles/sec API´s (application programmers interface) API´s continued Avoid to develop hardware oriented software Different standard 3D API´s: Minimize turnaround costs and time Many different available today. The most renowned are: Use well established and standardized 3D API´s PHIGS and GKS (old DEC machines, not common any longer) OpenGL (SGI, Microsoft, many others) Use graphics accelerators which support those API´s QuickDraw 3D (Apple) - full functional support Direct3D (Microsoft) - optimized performance