256 barev, OpenGL a problémy, na které jsme už zapomněli

Na lepší se zvyká vždycky snadno, a ač někdy rádi s nostalgií u technologií vzpomínáme na minulost, je třeba říct, že to tehdy zas taková idylka taky nebyla. V rámci svých počítačově-archeologických zálib se mi mimo jiné vybavilo, jak jsme tehdy existovali v dobách, kdy naše počítače zobrazovaly maximálně 256 barev. Je to jedna z těch věcí, co mi vůbec nechybí.

windows95-color-palette

Jedním z mých koníčků je zkoumání starých počítačů, a to zejména pokud jde o jejich grafické schopnosti. Z obyčejných 3D akcelerátorů v PC jsem se postupně probádal až k velkým vzácnostem pro profesionální trh, což už byl jen krůček do světa UNIXových pracovních stanic a grafických superpočítačů. Před časem tato snaha vykrystalizovala do vytvoření benchmarku pro měření čehokoli, co dokáže komunikovat s rozhraním OpenGL, a za pomoci dobrovolníků z celého světa se nám podařilo získat přes 100 výsledků (stále přibývají), a to převážně profesionálních karet (resp. počítačů). Je to sice totálně okrajová záležitost, ale přitahuje poměrně inteligentní a zajímavé lidi (bývalí inženýři grafických čipů, filmoví animátoři…), se kterými si pak vyměňuju spoustu zpráv.

Nedávno přišla řeč na 3D zobrazení u grafických karet, které neuměly zobrazovat současně více než 256 barev. Zatímco na PC byla obvykle podmínkou pro 3D akceleraci barevná hloubka alespoň 15, resp. 16 bitů (65 tisíc barev), existují i řešení, kde byla podpora OpenGL a jiných 3D rozhraní klidně s 256 nebo dokonce jen 16 barvami. A je to zajímavá etapa vývoje, protože, kdo si ještě pamatuje práci ve 256 barvách, ten ví, že to mělo jedno specifikum, které následně s většími barevnými hloubkami úplně odpadlo.

Práce s paletou

256 barev bylo super, když na ně člověk přecházel ze třeba ze šestnácti. To pak působilo jako hodně barev a speciálně to platilo třeba u nízkých rozlišení typu 320×200. U her a programů pod DOSem bylo všechno jednodušší, protože si vývojáři namíchali paletu barev přesně tak, jak se jim to bude hodit a pro takovou paletu pak všechno nakreslili. Paleta se následně buď vůbec neměnila, nebo jen částečně. Tohle bylo ok, dokud měl program celou obrazovku pro sebe a jakékoli uživatelské rozhraní si obsluhoval sám (podle potřeb třeba s úplným minimem barev).

Jenže jakmile dojde na okenní prostředí multitaskového operačního systému, začne být všechno poněkud komplikovanější a každý systém se s tím vypořádával po svém. Takový Windows si třeba ponechává 20 barev, na které nemá rád, když aplikace hrabe (což kromě případu celoobrazovkových programů vede k tomu, že si je mění zpět na to, co sám chce). Obsahuje základních 16 barev a k tomu čtyři, které slouží zejména v případě, kdy je ve Windows nastaven nějaký specifický barevný motiv (do palety se tak uloží například základní barvy oken programů). Výchozí barevný motiv Windows byl dělaný tak, aby používal jen těch základních 16 barev, a obyčejné programy se také snažily nechodit za tyto hranice. Pokud tedy pouze jedna z aplikací potřebovala využít barev více (a to tehdy byla celkem běžná situace ve Windows i v polovině 90. let), vše fungovalo perfektně.

win95-256c_007_17052020_191419

win95-256c_006_17052020_191413

Dva programy používající vlastní paletu (zbytek systému včetně pozadí se vejde do 16 základních barev). Paleta je vždy nastavena podle aktivního okna a druhý program má barvy špatně.

Jakmile jste si zapnuli více aplikací, které chtěly využívat více barev a vlastní palety, dočkali jste se efektu, který si možná mnozí ještě matně pamatují – při přepnutí mezi programy bliknuly barvy na obrazovce, jak se vyměnila paleta podle programu, který je zrovna aktivní, čímž se pokazily barvy v neaktivním programu. Vlastně ani nebylo potřeba mít takové programy dva. Stačil jeden a k němu si ještě na ploše nastavit nějaké 256barevné pozadí (čehož bylo lepší se vyvarovat). Pozadí plochy a k němu také webový prohlížeč Internet Explorer nicméně odchytávaly od systému události o změně palety a měly snahu adaptovat svoje barvy na cizí paletu. Takže u nich sice došlo k degradaci barevné hloubky, ale pokud to bylo aspoň trochu možné, barvy nebyly úplně mimo (tj. co má být například zelené, bude skutečně zelené tou nejbližší zelenou barvou, kterou má cizí paleta).

win95-256c_002_17052020_191245

win95-256c_004_17052020_191318

win95-256c_005_17052020_191330

(1) Systém s nastaveným 256barevným pozadím v  plné kvalitě. (2) Kvůli obrázku si webový prohlížeč zvolil vlastní paletu a pozadí použilo nejbližší barvy této palety. (3) Photoshop zobrazuje obrázek, kde nejsou žádné barvy podobné těm v pozadí, takže výsledek i přes snahu systému není dobrý.

U statických programů se tohle ještě celkem dá řešit, ale nepříjemnosti nastanou, jakmile dojde na 3D zobrazení a video. Soubory videí se nestarají o barevnou hloubku počítače, takže práce zůstává na straně tvůrce přehrávače, který většinou půjde cestou nějaké univerzální palety. Taková paleta sice není nejvhodnější pro každý jednotlivý snímek videa, ale zas ji není nutné po celou dobu přehrávání měnit. Kvalita zobrazení tím pochopitelně utrpí. Dobré je, že to není o tolik víc práce pro programátora, protože konverzi barvových prostorů by stejně musel řešit i pro vyšší barevné hloubky (video se obvykle ukládá jako YUV a ne RGB).

Je zajímavé, že některé grafické karty, které podporovaly video overlay (tj. přímé vykreslování obrazu videa na obrazovku) a akcelerovaly konverze z YUV na RGB, zobrazovaly video v plné barevné hloubce, i když byl Windows nastavený jen na 256 barev, takže další programy a palety je nijak neovlivňovaly.

3D zobrazení a OpenGL

Problém vzniká, pokud budete chtít pracovat s 3D zobrazením přes rozhraní OpenGL, které se ve Windows objevilo spolu s verzemi 95 a NT 3.5. Ideálně byste v něm totiž chtěli pracovat tak, že načtete model, který má nějaké barvy materiálů (případně přímo textury), a podle aktuálního nastavení světel se model automaticky vystínuje (což dodá dojem prostoru). Pokud jste pod Windows pracovali ještě v druhé půlce 90. let a zkusili spustit nějaký OpenGL program (téměř jistě se softwarovým vykreslováním), nejspíš jste zjistili, že má barvy úplně špatně, nebo zobrazuje jen černou. Většina vývojářů totiž palety vůbec neřešila, takže buď jen přidali chybovou hlášku, že program potřebuje vyšší barevnou hloubku, nebo nechali zobrazovat nesmysly.

OpenGL samo o sobě totiž palety vůbec neřeší a očekává RGB řazení barev, tedy že část bitů každého pixelu je vyhrazena pro červenou, zelenou a modrou složku (místo toho, aby všech osm bitů bylo pouze odkazem na číslo barvy v externí paletě). Jakmile není v systému nastavena paleta, která by používala stejně řazení jako RGB, jsou barvy špatně. Problém byl, že tahle paleta téměř jistě nastavena nebyla, protože pro systém nebyla výchozí. Musel si to ošetřit programátor, který ji v programu nastavil (v bitovém formátu „RRRGGGBB“). Jenže pak stejně vznikl problém, protože u okenního zobrazení začal zápasit s operačním systémem, který nechtěl svých 20 systémových barev nechat předefinovat (10 na začátku a 10 na konci palety). Ve výsledku tedy bylo nutné kód upravit tak, aby jakoukoli barvu, která by spadla do tohoto místa, nahradil nejbližší možnou ze zbytku palety (ideální pak bylo ještě upravit zbylé barvy, aby byly rozprostřené světlostí od černé do bílé).

Tohle všechno byla práce navíc, kterou se drtivé většině vývojářů nechtělo podstupovat. Přece jen OpenGL používaly především profesionální programy, takže vývojáři očekávali, že si zákazníci koupí odpovídající hardware, který umí více barev. U her v té době nebyl problém, protože si celý 3D rendering řešily ve svém vlastním vykreslovacím enginu, takže si barvy ošetřily stejně jako dříve pod DOSem (a nepoužívaly efekty, které by práci komplikovaly). 3D pod OpenGL s 256 barvami tak bylo na PC jenom takovou krátkou epizodou někdy mezi roky 1994 a 1996. Překvapilo mě, že dokonce existovaly grafické karty, které nepodporovaly víc jak 256 barev a přesto měly 3D akceleraci pod OpenGL (1.0). Jednou z takových grafik byla poměrně rychlá DEC PowerStorm 3D30 s čipem TGA2, který si Digital navrhnul sám a používal ho ve svých stanicích s procesory Alpha pod Windows i UNIXem (Tru64 UNIX). Pod Windows NT jsem však našel jen jediný dobový velký OpenGL program, který si paletu ošetřil. Jde o LightWave 3D 5.6. Pokud LightWave zjistí, že běží ve 256barevném módu, zakáže OpenGL zobrazení se stínováním. Ponechá jen možnost vykreslování, kdy všechny polygony mají stejnou barvu a jsou ohraničeny bílými čárami. Dohromady s pozadím jsou potřeba jen tři barvy, takže LightWave pracuje v režimu s indexovanými barvami a pevně zadává, kde se má která použít. Ve výsledku tak OpenGL zobrazení s takovou kartou nabízí jen zvýšení rychlosti, ale ne funkce navíc.

Z OpenGL programů, které si skutečně daly práci, aby ve 256 barvách fungovaly, znám jen přibalené 3D spořiče ve Windows (bludiště, rotující objekty…).

A co ostatní platformy?

Windows je vlastně poměrně chytrý, co se týká konverzí barev a snaží se práci programům usnadnit na všech frontách. Pokud tedy načtete ve svém programu obrázky, které mají jinou barevnou hloubku, automaticky je převede na tu, která je zvolená. Jiné systémy k programátorům aplikací takto velkorysé nejsou – týká se to většiny UNIXů i klasického Mac OS.

Pokud však jde o práci s paletou, vypadá to, že Mac OS pomáhá a snaží se, aby u neaktivních programů probíhalo to samé, co dělá Internet Explorer ve Windows. Tedy aktivní program si namíchá vlastní paletu a ostatní programy se přizpůsobí tak, aby při dané paletě vypadaly co nejlépe (jakkoli je to někdy nemožný úkol). Jak je to ovšem vnitřně řešeno, to netuším. Je možné, že se to snaží obsloužit přímo systém, ale také je možné, že je to připraveno v některém z toolboxů a Apple ve svých příručkách pro programátory definoval, jak to mají co nejjednodušeji používat.

Řešit OpenGL na Macu moc nemá smysl, protože do klasického systému se dostalo až velmi pozdě (v době, kdy se primárně vyvíjel Mac OS X), takže už tou dobou palety pro 256 barev nikoho netrápily.

UNIX: Sun Solaris

Zkušenost s 256 barvami a OpenGL mám nicméně na UNIXu. Konkrétně takový Solaris běžel běžně na počítačích od Sunu ve 256 barvách ještě ke konci 90. let (to už ovšem šlo hlavně o low-end modely). Mnohé UNIXové počítače obecně dlouho setrvaly u 256 barev a má to docela zajímavé důvody.

Ve světě PC se objevila velká spousta levných grafických karet s větším množstvím paměti a schopnými převodníky (RAMDAC) už začátkem 90. let, takže třeba v roce 1994 stál ISA Trident 8900D (1MB) pouhých $60, za které umožňoval 640×480 s 16 milióny barev, 800×600 s 65 tisíci barev a 1024×768 alespoň ve 256 barvách (a daleko schopnější karty byly pořád pod $200). Naopak výrobci UNIXových stanic obvykle nabízeli základní grafiky omezené fixně na 256 barev a cokoli lepšího bylo za tučný příplatek. Na jejich obranu bych měl uvést, že u UNIXových stanic byly obvykle lepší monitory s mnohem vyšším rozlišením. Takové rozlišení 1280×1024 bylo považováno za standard i pro základní modely, zatímco u PC byli v 90. letech mnozí rádi i za 800×600, kde stejná barevná hloubka měla třikrát nižší nároky na přenosové pásmo i velikost paměti.

Na rozdíl od Windows Sun a další ignorovali 16bitovou barevnou hloubku (high-color, 65 tisíc barev), takže další krok bylo až 24, resp. 32 bitů (true-color, 16 miliónů barev), čímž se masivní přechod na více barev ještě oddálil. 16bitová barevná hloubka byla v PC světě velmi oblíbená a spousta počítačů ji používala minimálně pro 3D akceleraci ještě klidně v roce 2003. Proč se tedy v profi světě UNIXu nepoužívala? Jeden ze zajímavých dobových důvodů je, že v určitých ohledech jde o krok zpět proti 256 barvám (8bitové barvy). V případě 256 barev si totiž můžete většinu namíchat libovolně (na UNIXu všechny). Pokud tedy chcete vizualizovat nějaký výstup měření, případně 3D objekt a stačí vám třeba jen odstíny červené (nebo jiný barevný gradient), můžete získat teoreticky až 256 různých odstínů této barvy (což je stejně jako v true-color a víc, než kolik dnes dokáže rozlišit leckterý moderní LCD/OLED panel). Jenže v high-color zobrazení se už daných 65 tisíc barev nepoužívá paletově. Pokud tedy bude 16 bitů rozděleno na 5-6-5 pro jednotlivé složky (počet bitů pro R-G-B), dá to jen 32 (červená, modrá), resp. 64 (zelená) různých odstínů dané barvy. Že by to asi pro většinu lidí byla malá daň za to, že celkově bude práce s barvami mnohem jednodušší, asi pravé puristy mezi vývojáři neobměkčilo. Kdo chtěl víc barev, měl si pořádně připlatit.

Sun měl velmi zajímavá grafická řešení (2D i 3D) vlastního návrhu už dávno (konec 80. let), případně později přeprodával profesionální karty od firem jako 3DLabs. Ale platilo to jen pro ty příplatkové. Základní grafiky byly opravdu základní. Ještě v roce 1998 vydal Sun počítače Ultra 5 a Ultra 10, kde umístil čipy ATI Rage Pro s 4 MB paměti na základní desku, kterou na rozdíl od stejně starých kancelářských PC nedoplnil slotem pro rozšíření video paměti na 8 MB. Čip, který uměl v PC světě akcelerovat Direct3D i OpenGL v 16bitové barevné hloubce, zde sloužil jen jako primitivní zobrazovadlo, které navíc ve výchozím rozlišení 1280×1024 nabízelo jen 256 barev (kvůli nedostatku paměti), a Sun si nedal práci ani s napsáním ovladače pro akceleraci videa.

solaris-8bit-opengl_03

256barevné zobrazení v režimu RGB 3-3-2 díky ditheringu nabízí přijatelnou kvalitu pro 3D vizualizace.

Z důvodu velkého rozšíření stanic, které pracovaly ve 256 barvách, udělal Sun softwarový ovladač OpenGL (mimochodem dost neoptimalizovaný) tak, aby přemíchal automaticky paletu na RGB 3-3-2, kdykoli je okno s OpenGL zobrazením aktivní. Díky tomu se výrobci programů nemuseli starat o specifickou podporu (ale mohli, když chtěli) a nějak to vždy fungovalo. Vzhledem k tomu, že se přemíchaly všechny barvy v systému, způsobilo to, že všechno okolo OpenGL zobrazení mělo barvy úplně mimo. Jakmile jste přepnuli na jiné okno, barvy se v systému opět spravily (a v OpenGL okně rozbily). Ideální situace to rozhodně nebyla, ale lepší než nic.

solaris-8bit-opengl_01

solaris-8bit-opengl_02

Paleta pro režim RGB 3-3-2 se automaticky nastaví, pokud je okno s OpenGL zobrazením aktivní. Tím se pokazí barvy celého zbytku systému. Pokud se přepne na jiné okno, poškodí se barvy v OpenGL.

UNIX: SGI IRIX

V SGI, tedy Silicon Graphics Inc., si inženýři dali větší práci s vyladěním grafického subsystému. Poslední stanicí, která v základní konfiguraci podporovala jen 256 barev, bylo SGI Indy (1993-1997), nicméně pod IRIXem nebyla 3D akcelerace s nízkou barevnou hloubkou žádný problém. Vlastně se dá říct, že systém byl na 256 barev velmi dobře připraven i v případě videa a 2D grafických programů. Nelze se ani divit, když IRIX byl od začátku navržen s tím, že 256 barev byla základní varianta v době, kdy taková grafická karta byla nejen drahá, ale zabírala třeba několik velkých plošných spojů a čítala desítky čipů.

8bitová grafika v Indy funguje podobně jako dřívější řešení od SGI. Pro každý pixel uchovává vedle 8 bitů definujících barvy ještě další 4 pomocné bity (RGB enable, double-buffer enable, overlay, underlay). Dva z nich slouží pro výběr barevného režimu ze čtyř možností:

  • RGB 3-3-2 grafika s jedním obrazovým bufferem (256 fixních barev)
  • Indexovaná paletová grafika s jedním obrazovým bufferem (256 libovolných barev)
  • RGB 1-2-1 grafika s dvěma obrazovými buffery (16 fixních barev)
  • Indexovaná paletová grafika s dvěma obrazovými buffery (16 libovolných barev)

Operační systém v základu používá 256 barev, které jsou v režimu RGB 3-3-2 a nejsou definovány externí paletou. Jde o odlišný přístup od všech ostatních, který sice znamená, že nedostanete nejlepší barevnou přesnost (červená a zelená složka mají po osmi úrovních, modrá jen čtyři), ale běžné aplikace i tak dostanou mnohem hezčí barvy, než když se ve Windows držely na základních šestnácti. Velkou výhodou je, že běžné aplikace v IRIXu se o paletu vůbec nemusí starat. Mohou fungovat úplně stejně jako ve vyšších barevných hloubkách a také při přepínání mezi nimi nedochází k blikání vlivem prohazování palet.

Pokud program chce maximální barevnou přesnost pomocí vlastní palety, stačí danou část okna přepnout do paletového režimu a inicializovat vlastní paletu (256 barev). Když tohle program udělá, stejně nedojde k žádnému blikání ostatních aplikací, či snad degradaci jejich barev. Prostě vedle základních (pevných) 256 barev dostanete dalších 256 barev, které si definujete sami. Tohoto fíglu využíval velmi chytře jak Photoshop, tak i další programy pracující s grafikou. Aplikace, kde to mělo smysl, často nabízely v menu možnost rychlého přepnutí, takže si uživatel mohl zvolit, kde mu stačí RGB mód a kde chce radši programem definovanou paletu.

sgi-irix-256-colors

256 barev na SGI vypadá mnohem lépe než na jiných počítačích. Může za to schopnost grafiky používat více palet současně.

Zajímavostí je ještě double-buffering. Protože byla paměť grafického čipu tak akorát velká, aby se tam vešlo osm barvových bitů na pixel a k tomu ještě čtyři pomocné, dochází k problému, jak akcelerovat real-time 3D zobrazení. Pokud jej má karta akcelerovat, je nutné, aby měla kde skládat nový snímek scény (back buffer) v době, kdy se na monitor vykresluje ten předchozí (front buffer). Řešení je takové, že při zapnutí dvojice snímkových bufferů karta jednoduše každý bajt (osm bitů) rozdělí na dva pixely po čtyřech bitech a každou z půlek přiřadí do jiného bufferu. Tímto rozhodnutím klesne barevná hloubka na šestnáct barev, u kterých na rozdíl od Windows můžete stále zvolit, jestli chcete pracovat v režimu RGB (zde již jen 1-2-1, tedy dvě úrovně pro červenou a modrou a čtyři pro zelenou), nebo si všech 16 barev sami namícháte.

16 barev v režimu RGB 1-2-1 vypadá jinak než klasických 16 barev, které znáte z PC. Vzhledem k tomu, že modrá a červená složka mají jen dva stupně intenzity (plná a žádná), není například možné vytvořit šedou. Výhodou naopak je, že se v tomto režimu grafickému čipu snadno pracuje. Některé programy využívaly možností grafiky pro maximální kvalitu. Pokud jste například 3D objektem ve scéně pohybovali, použil se double-buffering a 16 barev, ale jakmile jste myší objekt pustili, okamžitě se obraz překreslil v plné kvalitě 256 barev.

256 barev na SGI bylo o třídu jinde proti ostatním platformám (však to bylo vlastně až 528 různých barev na obrazovce). Absence vyšší barevné hloubky zde nebyla tak citelná. To je jedna z věcí, kterou člověk neměl šanci poznat z prospektů – to se prostě muselo zažít.

UNIX: HP-UX

Ve 256 barvách se systém od HP choval podobně jako Solaris. Pokud jste si nekoupili grafickou kartu, která podporuje 24bitovou grafiku, museli jste počítat s občasným poblikáváním barev. Pokud jde o 3D, tak HP podporovalo jen několik aplikačních rozhraní, která se nakonec neujala (Starbase, PHIGS, PEX), a k implementaci OpenGL (a GLX) došlo až v polovině roku 1998 s ovladačem pro karty Visualize-FX, které už se na 256 barev neomezovaly (popis architektury karty, popis OpenGL v HP-UX). Majitelé stanic s ostatními kartami měli nejspíš možnost leda tak softwarového vykreslování pomocí open source knihoven Mesa 3D (pokud si je sami zkompilovali) a HP svůj systém softwarovým renderingem podle všeho nevybavilo.

Občasné blikání obrazovky kvůli změnám palety samozřejmě inženýry v HP také netěšilo, a tak v první půlce devadesátých let do jejich low-cost grafických čipů (podporujících jen 256barevné módy) přidali druhou paletu a každý pixel měl v paměti další bit, který definoval, z jaké palety se barva využije. Oproti řešení od SGI šlo spíše o takový dodatečný hack. Pro aplikace byla tato funkce transparentní a systém v praxi využíval druhou paletu jen v případě, že aplikace ve sdílené paletě vyplýtvaly všechny barvy, anebo v situaci, kdy si aplikace řekla o celou svou paletu (nejčastější případ). Pokud taková na barvy náročná aplikace běžela jen jedna, k blikání vůbec nedocházelo.

hp-color-recovery

Další hezkou funkcí, která byla přidaná do low-cost řešení od HP, bylo HP Color Recovery. Do paměti grafiky se sice stále ukládal obraz s redukovanou barevnou hloubkou na 256 barev pomocí ditheringu, ale přídavný DSP obvod dokázal bez ztráty výkonu tento obraz, pokud to aplikace povolila, zrekonstruovat do stavu, který alespoň dle HP byl velmi podobný původní plné barevné hloubce. Kdysi jsem měl doma PA-RISC stanici od HP, která měla grafiku s podporou Color Recovery. Nějak jsem ovšem nenašel aplikaci, na které bych mohl tuto funkci vyzkoušet. Také mě zaujalo, že nikdo jiný podobný postup nenásledoval. V roce 1995 už to bylo asi moc pozdě.

Odbočka k Linuxu

V Linuxu se používala open source implementace X serveru Xfree86 a správa 256 barev byla stejná jako u jiných X serverů (HP-UX, Solaris…). Aplikace si mohla říct, zda bude používat sdílenou paletu, nebo si radši namíchá vlastní. Ve sdílené paletě bylo na začátku základních šestnáct barev a zbytek bylo možné definovat přes funkce X serveru. Program tedy například mohl říct, že chce barvu „DeepPink4“ a systém mu v paletě vyhradil přesně definovanou tmavě fialovou. Výhodou takového přístupu bylo, že pokud jiný program chtěl stejnou barvu a definoval ji také pomocí systémového názvu, fakticky byla tato barva v paletě grafické karty jen jednou.

V případě použití vlastní palety se X server nebrání přenastavení všech barev, což pak může vést k tomu, že úplně celá plocha a dekorace oken mají nesmyslné barvy (jako u OpenGL na Solarisu), pokud je okno s vlastní paletou aktivní.

Když už jsem tak bádal, zaujalo mě, jak to vlastně s Linuxem bylo, pokud jde o OpenGL a 3D akceleraci obecně. Brian Paul z AVIDu začal dělat ve volném čase knihovnu Mesa 3D (fakticky implementaci OpenGL) poměrně záhy, co SGI uvolnilo specifikaci. Sám měl v práci stanice od SGI, což celou situaci nepochybně také zjednodušilo. Mesa jako taková však byla dlouho pouze softwarové vykreslování přes procesor a nepoužívala hardwarovou akceleraci.

3dfx-voodoo-graphics

Přídavný 3D akcelerátor 3Dfx Voodoo Graphics se připojoval mezi hlavní grafickou kartu a monitor pomocí dvou VGA konektorů.

Kdo chtěl 3D pod Linuxem, musel počkat až někdy do začátku roku 1998, kdy vznikla Linuxová portace knihoven rozhraní 3Dfx Glide. Podporovány byly přídavné akcelerátory 3Dfx Voodoo Graphics, které nesloužily jako plnohodnotné grafické karty (kdo si to pamatuje z Windows, karta převzala práci pouze při spuštění hry a zobrazovala vždy přes celou obrazovku).

Když už bylo v Linuxu rozhraní Glide, které komunikovalo přímo s hardwarem, stačilo modifikovat knihovnu Mesa tak, aby v podstatě překládala volání OpenGL programů na Glide. Přídavné akcelerátory od 3Dfx sice nebyly zrovna tím, co by bylo v UNIXovém světě považováno za ideální 3D řešení pro seriózní programy (pouze celoobrazovkový režim, jen 65 tisíc barev a textury maximálně 256×256 pixelů), ale pod Linuxem to byla první možnost akcelerovat OpenGL. Na Linux byl navíc portován GLQuake a Quake2, takže tu byl i nějaký smysl pro tuto akceleraci.

V polovině 1998 už byla rozšířena podpora o další grafická řešení 3Dfx (Voodoo Rush, Voodoo2). Dokonce bylo možné pomocí speciálního hacku akcelerovat 3D v okně. Přídavný akcelerátor se nastavil do režimu, kdy nepřevezme zobrazení na monitor, a knihovna Mesa kradla hotový obraz z jeho paměti, aby ho ručně přesunula do hlavní grafické karty. Bylo to pomalé, ale mnohdy stále rychlejší než softwarové vykreslování.

Podpory dalších grafických čipů se Linuxáci dočkali až začátkem roku 1999. Začalo to opatrně prototypem ovladače pro tehdy oblíbený čip 3DLab Permedia2. O půl roku později s Linuxovým jádrem 2.2 byl vyřešen problém, aby 3Dfx karty nepotřebovaly pro akceleraci oprávnění správce (root) a komunitně se začalo pracovat na ovladači pro Matrox G200 (taktéž velmi oblíbené řešení). Na podzim už byl ovladač pro karty od Matroxu hotový (G200 i G400) a dokonce přichází NVIDIA s oficiálním binárním ovladačem pro všechny svoje karty od Riva128 po TNT2 (ovladač byl společný a rychle zahrnul podporu pro každou další kartu záhy po jejím uvedení).

Krok NVIDIE byl pro některé překvapením, protože NVIDIA se nestavěla nejlépe k open source a nechtěla dávat programátorské specifikace dalším vývojářům. Fakticky ovšem její binární ovladač fungoval ze všech nejlépe a nabízel nejvyšší výkon (což teda platí asi dodnes).

V první půlce roku 2000 vychází Xfree86 4.0 a podpora 3D akcelerátorů se rozšířila i o další komunitní ovladače (ATI Rage Pro, Rage128, Intel i810, Voodoo3, SiS 6326, S3 Virge) a šance, že náhodný počítač pod Linuxem bude alespoň nějak akcelerovat 3D zobrazení se výrazně zvýšila.

Sám jsem začal používat 3D akceleraci na Linuxu asi právě někdy mezi 2000 a 2001 na své NVIDIA Riva TNT2 M64 a díky oficiálnímu binárnímu ovladači jsem se v počátcích vyhnul řadě nepříjemností.

Závěrem

Měl jsem v 90. letech počítač, takže si pamatuju, kolik problémů 256barevné zobrazení později přinášelo. Zpětně však musím uznat, že jsem Windows trochu křivdil a řešení od Microsoftu bylo poměrně promyšleným kompromisem. Že to nebylo ideální, bylo prostě dáno omezením hardwaru, a výrobci, kteří si neupravili spolu se systémem i grafický čip, nenabídli o nic lepší výsledky.

Lidé od PC nakonec měli výhodu v jejich „prťavých“ monitorech s nízkým rozlišením a využití mezistupně v podobě 16bitové barevné hloubky (65 tisíc barev), čímž se snížily hardwarové nároky na možnost úniku ze světa paletových grafických režimů.

Zajímavé srovnání nabízí příchod OpenGL na různé platformy. SGI jej mělo hned od roku 1992, což je logické, když s ním přišlo. PC však bylo mezi prvními platformami, které jej adoptovaly. Do Linuxu se v podobě Mesa 3D dostalo v roce 1995 (akcelerované pořádně až od 1999). Windows NT (3.5) jej měl už v roce 1994 a do dvou let se dostalo i na Windows 95. Sun si počkal do 1995 a HP do 1998.

Zajímalo by mě, jestli by se OpenGL nakonec rozšířilo, kdyby jej tým Windows NT tehdy nechtěl do svého systému. Technicky bylo sice asi nejlepší v porovnání s konkurencí, ale Microsoft a stoupající popularita PC mu dost pomohly, a to přestože po příchodu Direct3D jakékoli snahy o podporu OpenGL prakticky vymizely (SGI dokonce později vydalo vlastní, mnohem rychlejší softwarový OpenGL renderer pro Windows).

Komentáře k článku

  1. 1. mixal11  24.5.2020  20:38:18

    Diki za krásne čítanie! Paletové trable si pamätám,aj keď nie s opengl. Veľmi zaujímavé boli pre mňa informácie o pociatkoch OPENGL Linuxe, 3DFX atd

  2. 2. nula  24.5.2020  20:45:49

    Moc pěkné čtení. SGI Indy v 8bit režimu jsem reálně viděl jen párkrát. Musím si to zkusit na starém Indigu s Entry grafikou…

    Trochu si vzpomínám. že až roku 1998 jsem běžně používal 14″ černobílý monitor (na PC s Windows), takže mě problémy s barvami tolik netrápily..

  3. 3. swarm  25.5.2020  17:29:19

    [3] Jakou máš verzi OS na Indigu? Pokud je tam nějaká, kde je alespoň OpenGL 1.0, tak by mě docela zajímal .log výstup z našeho benchmarku, kde je vypsaný OpenGL renderer a jeho funkce. Bylo by zajímavé to otestovat, protože k Entry grafice není pořádně nikde moc informací. Mluví se o tom, že je velmi primitivní a nic neumí, ale reálně je tam předchozí verze REX čipsetu (Indy XL), takže by to mohlo mít nějaké funkce pro urychlení vykreslování i pokud jde o 3D zobrazení.

  4. 4. nula  26.5.2020  15:14:41

    [3] Mam tam IRIX 5.3.

    Verze 6.5 by se mi asi na disk nevesla (i kdyz je to R4k Indigo, kde by mela fungovat).

    Pisu z O2, takze radsi bez diakritiky…

  5. 5. r443  4.6.2020  17:57:30

    Perfektní článek, spousta zajímavých informací a souvislostí, které jsem dříve neviděl. Já vím, proč se sem rád vracím.. díky!


Napsat komentář