Obsah
1. Popis činnosti grafického systému Reality Engine
2. Transformace vrcholů a normálových vektorů, odstranění neviditelných částí polygonů
3. Zpracování transformovaných polygonů rozložených na trojúhelníky
5. Operace s fragmenty a antialiasing
6. Obsah následující části seriálu
1. Popis činnosti grafického systému Reality Engine
V předchozí části seriálu o architekturách počítačů jsme si řekli, z jakých modulů se skládá grafický subsystém Reality Engine používaný na některých výkonných počítačích firmy SGI. Víme již, že celý subsystém je sestaven z několika samostatných desek nazvaných geometry board, raster memory board a display generator board. V závislosti na tom, jaký výkon při zobrazování prostorové grafiky vyžaduje uživatel, může být celý grafický subsystém Reality Engine sestaven ze tří, čtyř nebo šesti desek (to znamená, že některé desky a tím i grafické moduly, jsou v systému použity vícekrát a mohou pracovat paralelně). První deska grafického subsystému obsahuje jeden procesor příkazů (Command Processor) a několik bloků, které zpracovávají geometrické informace (Geometry Engines). Na druhé desce se nachází generátory fragmentů (Fragment Generators) a pole procesorů určených pro zpracování bitmap a finální vykreslování fragmentů do framebufferu s využitím antialiasingu (Image Engines). Poslední deska slouží pro zpracování výsledného rastrového obrazu a pro generování video signálu určeného pro monitory popř. pro další vhodná grafická výstupní zařízení.
Obrázek 1: Funkční bloky grafického subsystému Reality Engine.
V předchozí části tohoto seriálu jsme se také dozvěděli, jakou funkci v grafickém subsystému vykonává procesor příkazů (Command Processor) – ten slouží k postupnému načítání příkazů z fronty (typu FIFO – First In, First Out), do níž jsou příkazy předávány grafickou knihovnou OpenGL. Každý příkaz je po zavolání nějaké výkonné funkce OpenGL převeden na sekvenci řídicích kódů a parametrů, které jsou následně uloženy do fronty. Procesor příkazů některé příkazy dokáže sdružovat takovým způsobem, aby byly prováděny na jednom Geometry Enginu (viz další kapitolu) a naopak dlouhou sekvenci vzájemně nesouvisejících příkazů (popř. i polyčáry či velké pruhy a trsy trojúhelníků) dokáže korektně rozložit (distribuovat) mezi několik Geometry Enginů takovým způsobem, aby byly všechny další moduly grafického subsystému Reality Engine vytíženy v co největší míře rovnoměrně, neboť jen tak lze zajistit paralelní běh všech grafických algoritmů.
Obrázek 2: Čtyři desky, ze kterých se skládá grafický subsystém Reality Engine. Existuje i méně výkonná konfigurace se třemi deskami a naopak výkonnější konfigurace obsahující šest desek.
2. Transformace vrcholů a normálových vektorů, odstranění neviditelných částí polygonů
Každý modul Geometry Engine je sestaven z RISCových procesorů Intel i860XP, které dokážou provádět jak aritmetické operace s celočíselnými operandy, tak i s operandy reprezentovanými ve formátu pohyblivé řádové čárky (floating point), což je i jeden z důvodů, proč se firma SGI rozhodla tyto procesory v systému Reality Engine použít. Každý modul Geometry Engine dokáže provádět různé transformace souřadnic vrcholů i jejich normálových vektorů na základě zadaných transformačních matic, odstranění odvrácených polygonů, polygonů ležících mimo viditelný prostor atd. Některé výpočty jsou prováděny v jednoduché přesnosti (což odpovídá datovému typu float či single), ovšem další výpočty vyžadují použití dvojité přesnosti (datový typ double). Transformované polygony jsou navíc rozděleny na trojúhelníky, které jsou následně poslány na sběrnici nazvanou Triangle Bus.
Obrázek 3: Blokové schéma jednoho modulu Geometry Engine. Zde můžeme vidět, že se tento uzel skládá z procesoru Intel i860XP, paměťového čipu a taktéž zákaznického obvodu určeného pro komunikaci s okolními čipy.
První verze algoritmů implementovaných v modulech Geometry Engine byly napsány v čistém céčku; veškerý vývoj byl prováděn na systémech s procesory MIPS, ovšem výsledný kód byl generován přímo pro procesory Intel i860XP. Po odladění a patřičném otestování všech algoritmů vývojáři zjistili, které části implementovaných algoritmů jsou prováděny nejčastěji. Následně byly tyto části přepsány do assembleru (jazyka symbolických instrukcí/adres) s důrazem na co nejlepší využití všech výpočetních jednotek, které tyto procesory mají – kromě klasické aritmeticko-logické jednotky (ALU) totiž tyto procesory obsahovaly i dvě jednotky určené pro provádění operací s operandy v pohyblivé řádové čárce. Jedná se o FP adder s jehož pomocí bylo možné provádět součty, rozdíly, porovnání a konverze čísel uložených v systému plovoucí řádové tečky. Druhá jednotka nazvaná FP multiplier sloužila k součinu dvou čísel a taktéž k výpočtu převrácené hodnoty. Všechny tři základní jednotky, tj. ALU, FP adder a FP multiplier pracovaly paralelně, přičemž paralelismus byl podporován přímo v instrukční sadě, která byla typu VLIW (jedno instrukční slovo obsahuje bloky bitů, z nichž každý představuje instrukci určenou pro jednu výpočetní jednotku).
Obrázek 4: Mikroprocesor Intel i860.
3. Zpracování transformovaných polygonů rozložených na trojúhelníky
Každý modul Geometry Engine při své činnosti vytváří sérii trojúhelníků s transformovanými vrcholy i normálovými vektory doplněnými informací o sklonu trojúhelníků ve směru os x a y, které jsou následně posílány na Triangle Bus, což je interní sběrnice grafického systému Reality Engine, která dokáže přenášet data mezi jakýmkoli Geometry Enginem a kterýmkoli generátorem fragmentů (Fragment Generator). Existence jediné sběrnice, na jejímž vstupu je osm či dvanáct Geometry Enginů a na výstupu ještě větší množství generátorů fragmentů, by mohla znamenat riziko potenciálního vzniku úzkého hrdla celé architektury, protože v jeden okamžik je možné propojit pouze jediný Geometry Engine s jediným generátorem fragmentů. Tvůrci popisované grafické architektury se vzniku úzkého hrdla, jež by celou architekturu grafického subsystému znehodnotilo, bránili dvěma způsoby – minimalizací času, který je nutný pro arbitráž sběrnice (tj. rozhodování, mezi kterými moduly se budou v daném okamžiku přenášet data a který přenos dat bude mít přednost před ostatními přenosy) a samozřejmě také zvýšením vlastní přenosové rychlosti.
Obrázek 5: Pruh čtyřúhelníků (quad strip). Jedná se o jeden typ geometrické entity podporovaný knihovnou OpenGL. Před vlastní rasterizací se pruh čtyřúhelníků rozloží na samostatné čtyřúhelníky a následně se každý čtyřúhelník rozloží na dvojici trojúhelníků. Teprve tyto trojúhelníky jsou distribuovány mezi jednotlivé moduly Geometry Engine.
Přenosová rychlost této interní sběrnice je tak velká, aby umožnila vykreslení více než jednoho milionu otexturovaných trojúhelníků za sekundu při povoleném antialiasingu i zapnutém Z-bufferu (tj. při porovnávání vzdáleností vytvářených fragmentů od pozorovatele s případným vyloučením těch fragmentů, které jsou překryty jiným, již dříve vykresleným fragmentem). Vzhledem k tomu, že osm či dvanáct Geometry Enginů dokáže v ideálním případě, tj. při dokonalé distribuci práce mezi všechny moduly, generovat jen přibližně 500 000 až 700×000 trojúhelníků za sekundu, nedochází zavedením jediné sběrnice do celé architektury ke vzniku úzkého hrdla, i když se na druhou stranu omezily možnosti dalšího rozšiřování této architektury o další moduly Geometry Engine a generátory fragmentů (k významnějším kolizím na sběrnici by došlo v případě použití přibližně patnácti modulů Geometry Engine).
Obrázek 6: První deska obsahující procesor příkazů a osm procesorů Intel 860 (Geometry Engine) spolu s dalšími obvody zajišťujícími vzájemnou komunikaci všech čipů.
4. Rasterizace trojúhelníků
Každý trojúhelník, který byl transformován v modulu Geometry Engine, je následně přes výše popsanou sběrnici Triangle Bus poslán do pěti, deseti nebo dokonce dvaceti modulů nazvaných Fragment Generator, v nichž je provedena vlastní rasterizace a uložení fragmentů do framebufferu. Proces rasterizace se u grafického systému Reality Engine příliš neliší od operací, které jsou prováděny i na dnešních grafických akcelerátorech – nejprve se provede prvotní inicializace fragmentů s vhodnými počátečními hodnotami, vytvoří se subpixelová bitová maska obsahující příznaky, které fragmenty se mají skutečně vykreslit (ostatní leží mimo rasterizovaný trojúhelník), vypočte se adresa prvního texelu v texturovací paměti, popř. se vypočtou parametry používané pro modulaci textur, provede se výpočet osvětlení a nakonec se barva výsledného fragmentu může modifikovat barvou mlhy (fog) na základě vzdálenosti fragmentu od pozorovatele nebo se barva smíchá s barvou již dříve vykresleného fragmentu (blending).
Obrázek 7: Druhá deska, z níž se skládá grafický subsystém Reality Engine. Na této desce jsou umístěny generátory fragmentů sloužící k vlastní rasterizaci objektů a taktéž pole modulů Image Engine(s) určených pro provádění operací nad jednotlivými fragmenty.
Všechny výše zmíněné grafické operace jsou implementovány jako pipeline, která obsahuje velké množství řezů (slices), což znamená, že vykreslení jednoho fragmentu sice může trvat poměrně dlouhou dobu, protože data musí projít všemi řezy pipeline, ovšem v jednu chvíli se zpracovává větší množství fragmentů (jejich počet odpovídá počtu řezů), samozřejmě každý v jiné části vykreslovací (renderovací) pipeline. Vzhledem k tomu, že je každý trojúhelník, resp. jeho část, poslán do 5, 10 či 20 těchto modulů, musí každý Fragment Generator vykreslit pouze 20% (100/5), 10% (100/10) či jen 5% (100/20) fragmentů každého trojúhelníku, což samozřejmě představuje velmi významné urychlení vykreslování. Každý generátor fragmentů je implementován pomocí dvou ASIC čipů a osmi paměťových modulů DRAM – viz též následující obrázek, na kterém je nakresleno blokové schéma jednoho generátoru fragmentů spolu s jeho vstupními i výstupními částmi.
Obrázek 8: Blokové schéma jednoho generátoru fragmentů, který je složen ze dvou čipů ASIC a osmice paměťových modulů DRAM.
5. Operace s fragmenty a antialiasing
Fragmenty vytvářené ve výše popsaných generátorech fragmentů byly následně distribuovány mezi šestnáct modulů nazvaných Image Engine. Hlavním úkolem těchto modulů bylo zajistit operace prováděné na subpixelové úrovni, protože grafický systém Reality Engine podporoval, jakožto dobové hi-end řešení 3D akcelerace, vykreslování s využitím antialiasingu, které bylo prováděno supersamplingem, což znamená, že se pro každý vykreslovaný pixel generovalo větší množství vzorků, které byly následně vhodným způsobem zkombinovány ve výslednou barvu pixelu. Každý modul Image Engine získal od generátoru fragmentů poměrně značné množství informací, především vzdálenost středu fragmentu od pozorovatele, sklon fragmentu v osách x a y (fragment si můžeme představit jako malý čtvereček ležící na vykreslovaném trojúhelníku) a taktéž již v předchozí kapitole zmiňovanou bitovou masku o rozlišení 8×8, ve které bylo pomocí hodnoty jednotlivých bitů (0, 1) určeno, které části fragmentu leží uvnitř vykreslované plochy a které naopak vně.
Obrázek 9: Blokové schéma jednoho modulu Image Engine.
Modul Image Engine následně s využitím informace o vzdálenosti středu fragmentu a jeho sklonu vypočítal přesné vzdálenosti všech 8×8 subpixelů, provedl porovnání těchto vzdáleností s údaji uloženými ve framebufferu (jedna hloubka/vzdálenost pro každý fragment), aplikoval barvu vypočtenou generátorem fragmentů na viditelné subpixely a následně vypočítal výslednou barvu fragmentu, která byla posléze uložena do framebufferu. Každý modul Image Engine obsahoval část framebufferu o kapacitě 256k×16 bitů implementovanou pomocí paměťových modulů DRAM. Hloubka fragmentů byla uložena na 32 bitech, barva každého fragmentu mohla mít 12 bitů pro každou barvovou složku (red, green, blue), což znamená 36bitovou barvovou hloubku (6.8×1010 barevných odstínů).
Obrázek 10: Třetí deska s čipy zajišťujícími výstup video signálu na různá zobrazovací zařízení – monitory atd.
6. Obsah následující části seriálu
V následující části seriálu o architekturách počítačů na chvíli odbočíme od popisu grafických systémů používaných na hi-end grafických stanicích. Na základě žádostí čtenářů se totiž budeme zabývat způsobem tvorby grafiky na osmibitových domácích počítačích. Vzhledem k tomu, že jsme si již některé známé osmibitové domácí počítače (především osmibitová Atari, Commodore C64 i Sinclair ZX80, Sinclair ZX81 a samozřejmě také ZX Spectrum) v tomto seriálu popsali, zaměříme se příště především na ty osmibitové počítače, které byly zkonstruovány v bývalé ČSSR i některých okolních zemích. Bude se jednat například o chvalně i nechvalně známé stroje IQ 151, PMD 85 (jeho různé varianty), Ondra, MAŤO, Didaktik Alfa, Didaktik Kompakt či Didaktik Gama, které byly většinou osazeny osmibitovým mikroprocesorem 8080 popř. Z80 (resp. jeho východoněmeckou variantou U880). Pro některé z těchto počítačů existují i emulátory pro různé operační systémy (včetně Linuxu), takže pamětníci si mohou zavzpomínat například nad hrou Hlípa na dobu, kdy světu vládl Basic a ne C# :-)
Obrázek 11: Legendární IQ 151, které kromě funkce počítače mohlo v domácnostech i školách sloužit jako elektrický přímotop.
7. Literatura
- Fuchs, H., Goldfeather, J., Hultquist, J., Spach, S., Austin, J., Brooks, F., Eyles, J., and Poulton, J.,:
„Fast Spheres, Shadows, Textures, Transparencies, and Image Enhancements in Pixel-Planes“
Computer Graphics (SIGGRAPH '85 Conference Proceedings), Vol. 19, No. 3, July, 1985, pp 111–120. - Fuchs, H., Poulton, J., Eyles, J., Greer, T., Goldfeather, J., Ellsworth, D., Molnar, S., Turk, G., and Israel, L.,:
„A Heterogeneous Multiprocessor Graphics System Using Processor-Enhanced Memories“
Computer Graphics (Proceedings of SIGGRAPH '89), Vol. 23, No. 3, pp 79–88. - Poulton, J.,:
„Building Microelectronic Systems in a University Environment“
Proceedings of the 1991 Conference on Advanced Research in VLSI, (invited presentation) UC-Santa Cruz, March 25–27, 1991, pages 387–400. - Andries van Dam, Steven K. Feiner, John F. Hughes:
„Computer Graphics: Principles and Practice in C“
(2nd Edition) - Henry Styles and Wayne Luk:
„Customising Graphics Applications: Techniques and Programming Interface“
Department of Computing, Imperial College, London, England - Akeley, Kurt: „RealityEngine Graphics“
Proceedings of SIGGRAPH '93, pp. 109–116.
8. Odkazy na Internetu
- Pixel-Planes Project
http://www.cs.unc.edu/~pxfl/history.html - Pixel-Plane 5
http://www.cs.sunysb.edu/~vislab/papers/pvr/rpe/node27.html - Tiled rendering
http://en.wikipedia.org/wiki/Tiled_rendering - PowerVR
http://en.wikipedia.org/wiki/PowerVR - High-Performance Graphics Architectures: The Pixel-Planes Group
http://www.cs.unc.edu/~pxfl/pxpl-summary.html - Reality Engine
http://en.wikipedia.org/wiki/RealityEngine - Geometry pipelines
http://en.wikipedia.org/wiki/Geometry_Engine - SGIstuff : Hardware : Graphics : RealityEngine
http://old.sgistuff.net/hardware/graphics/reality.php - Onyx2 Technical Specification
http://vintagecomputers.info/onyx2/tech_specs.html - Video Technology Magazine – various graphics resolutions
http://www.videotechnology.com/0904/formats.html - Ultra XGA (Ultra eXtended Graphics Array)
http://www.pcmag.com/encyclopedia_term/0,2542,t=UXGA&i=53603,00.asp - UXGA (Ultra eXtended Graphics Array)
http://en.wikipedia.org/wiki/UXGA - WUXGA (Widescreen Ultra eXtended Graphics Array)
http://en.wikipedia.org/wiki/WUXGA - Video Standards (Graphics resolutions)
http://en.wikipedia.org/wiki/File:Vector_Video_Standards2.svg - The MIPS R10000 Superscalar Microprocessor (článek dostupný členům ACM)
http://portal.acm.org/citation.cfm?id=623999 - Glide API
http://en.wikipedia.org/wiki/Glide_API - Scientific Application of OpenGL Vizserver within High Performance Computing
http://www.ukhec.ac.uk/publications/reports/vizserver_casestudy_dec02.pdf - Amdahl's law
http://en.wikipedia.org/wiki/Amdahl%27s_law - NUMA: Frequently Asked Questions
http://lse.sourceforge.net/numa/faq/ - NUMA (Numa Support in Linux)
http://oss.sgi.com/projects/numa/ - Symmetric multiprocessing
http://en.wikipedia.org/wiki/Symmetric_multiprocessing - Non-Uniform Memory Access
http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access - Northbridge (computing)
http://en.wikipedia.org/wiki/Northbridge_(computing) - Southbridge (computing)
http://en.wikipedia.org/wiki/Southbridge_(computing) - Carrier sense multiple access with collision detection
http://en.wikipedia.org/wiki/Carrier_sense_multiple_access_with_collision_detection - Intel i740
http://en.wikipedia.org/wiki/Intel740 - Intel i740 Datasheet
ftp://download.intel.com/support/graphics/intel740/29061902.pdf - Intel740™ Graphics Accelerator P854 Hardware
ftp://download.intel.com/support/graphics/intel740/29062202.pdf - S3 Savage
http://en.wikipedia.org/wiki/S3_Savage - Savage (S3)
http://www.economy-point.org/s/savage-s3.html - 3dfx Interactive
http://en.wikipedia.org/wiki/3dfx_Voodoo_Graphics - Visualization Tools and Environments for Very Large Data
http://ditwww.epfl.ch/SIC/SA/publications/SCR00/scr12-page9.html - Intel 860@cpu-collection
http://www.cpu-collection.de/?l0=co&l1=Intel&l2=i860 - S3 Graphics
http://www.s3graphics.com/en/index.aspx - TSENG ET6000 Performance Page
http://dani75.tripod.com/TSENG.htm - Tseng Labs Ships ET6000 Advanced Graphics Chip, Announces Additional Manufacturing Sources
http://www.encyclopedia.com/doc/1G1–18088868.html - CyberMax chooses Tseng Labs' ET6000 Graphics and Video Controller for Max and ProMax Series PCs
http://findarticles.com/p/articles/mi_m0EIN/is_1996_Oct9/ai_18754932/ - Intel i860
http://en.wikipedia.org/wiki/Intel860 - Intel i860 64-Bit Microprocessor
http://www.microprocessor.sscc.ru/i860.html - 25 Microchips That Shook the World
http://www.synbio.org.uk/scientific-computing-news/1351.html - Sprite (computer graphics)
http://en.wikipedia.org/wiki/Sprite_(computer_graphics) - Sprite (počítačová grafika)
http://cs.wikipedia.org/wiki/Sprite_(počítačová_grafika) - Wikipedia: Video Display Controller
http://en.wikipedia.org/wiki/Video_Display_Controller - 3dfx Voodoo1 PCI
http://www.v3info.de/english/html/v1.shtml - Glide 2.2 Programming Guide
http://www.gamers.org/dEngine/xf3D/glide/glidepgm.htm - OpenGL Vizserver 3.1 Application Transparent Remote Interactive Visualization and Collaboration
http://subs.emis.de/LNI/Proceedings/Proceedings55/GI-Proceedings.55–20.pdf
