UNIX 14. Grafický subsystém © Milan Keršláger

Historie zobrazování ● textové terminály → Unix ● aplikace používají knihovny ● základní podpora terminálu uvnitř jádra OS ● 8bitové počítače (ZX Spectrum, IQ151,...) ● funkce v ROM, aplikace je volá ● základem textový režim (terminál) ● grafika pomocí specifických funkcí – každá aplikace typicky vlastní podle svých potřeb – nepřenositelnost graf. aplikací – přesto zajímavá a rychlá grafika (nejvíce hry)

IBM PC ● MDA (1981) – IBM ● IBM, černobílý textový režim (80x25) → dodnes ● Hercules (1982) ● grafický režim 720×348, stává se standardem ● CGA (1981), EGA (1984) – IBM ● barevné, ale málo barev, nízké rozlišení ● VGA (1987) – IBM ● maximálně 256 barev ● základem textový režim MDA, až 512 znaků ● stala se standardem v PC

VESA ● každý výrobce měl vlastní „vylepšení“ VGA ● dodnes se zachovává zpětná kompatibilita s VGA ● vylepšení však kompatibilní nejsou – kvůli specifickému ovládání nových vlastností ● VESA (Video Electronics Standards Association) ● (pomalá) standardizace vyšších rozlišení ● jednotné ovládání → VESA BIOS Extensions – uloženo v ROM grafické karty → sada ovládacích funkcí – výrobce ve svém BIOSu řeší specifické ovládání karty – někdy je možná aktualizace na novější VESA standard ● nezahrnuje však akcelerované funkce

Ovladače grafické karty ● VESA standard neumí využít akcelerované fce. ● funkce VESA BIOSu nejsou optimalizované ● v DOSu se grafické funkce neřeší ● aplikace musí ovládání karty řešit individuálně ● aplikace nebo hra funguje jen s některým hardware ● GUI (grafické uživatelské prostředí) ● tj. Windows, unixové OS s X Window System ● aplikace používají univerzální API funkce ● API funkce realizována ovladačem konkrétní karty – ovladač tvoří výrobce HW

Vytvoření obrazu ● grafická karta má svoji paměť (VideoRAM) ● vyhrazená → paměť pouze pro graf. kartu ● sdílená → vyhrazená část operační paměti RAM ● monitor např × 768, 32bpp ● 1 bod na 32 bitů → 2 32 barev (4 miliardy) ● obraz je řada bodů v řádcích (tzv. framebuffer) ● program zapisuje do VideoRAM čísla ● karta údaje čte a vykreslí příslušně barevné body ● 1024 × 768 × 32 = bitů = 3 MB ● volná paměť obsahuje bitmapy fontů, skrytá okna... – urychlení vykreslování obrazu → akcelerace

Akcelerované 2D funkce ● problém rychlosti zobrazování ● velké přesuny dat (mezi RAM a VideoRAM) ● snaha o odlehčení práce CPU (řeší to GPU) ● blitting – přesuny obdélníkových částí bez CPU – typicky pohybující se postavička ve hře ● hardware cursor – ukazatel myši – není zapisován do obrazu, přidá se na pozici do výstupu ● offscreen object – mimo framebuffer – celé okno vykresleno v RAM, akcelerace řeší překryvy, transfery objektu do framebufferu bez účasti CPU atd. ● a další akcelerované funkce...

3D akcelerace ● 2D akcelerace se dnes dělá pomocí 3D funkcí ● 3D objekty ● uloženy ve VideoRAM (i „neviditelné“ části) ● GPU renderuje objekty, řeší viditelnost, světlo,... ● obraz již nemá ve VideoRAM bitovou mapu 1:1 ● kompozitní správci oken ● program zapisuje (bitmapu) do bufferu ● buffer se skládají a transformují a pak zobrazení – umožňuje průhlednost oken, plochy na kostce, vlnění...

OpenGL ● 1992 – Silicon Graphics, Inc. ● dnes neziskové konsorcium Khronos Group ● programátorské API pro 2D a 3D funkce ● nezávislé na programovacím jazyku i HW platformě ● otevřený standard ● open source implementace → Mesa 3D ● původně pro 3D realizované pomocí CPU ● umí použít akcelerované funkce v HW karty

Direct3D ● 1996 – Microsoft (součást DirectX 2.0) ● proprietární 3D API s těsnou vazbou na HW ● nativní jen pro MS Windows a Xbox – uzamyká aplikace (hry) na MS platformě ● emuluje vertexové shadery, ale ne pixelové ● součást DirectX (ještě -Music, -Play a -Sound) ● od verze 8 též 2D (nahrazuje DirectDraw) ● dnes na úrovni OpenGL (design, rychlost) ● verze DirectX vzájemně nekompatibilní ● k nové verzi nutnost kupovat nový HW

OpenGL v Linuxu ● Galium3D a DRM jsou obecné knihovny ● DRI a DRM_karta řeší HW závislosti Grafická karta Ovladače: DRM + DRM_karta Mesa (knihovna) Galium3D + DRI Aplikac e Jádro OS Hardware

Direct3D ve Windows Grafická karta Ovlada č GDI Direct3 D Aplikac e ● GDI – vykreslování oken, widgetů ● podobně jako GTK+, Qt nebo Xlib Jádro OS Knihovny Hardware

GUI a jádro OS ● jádro spravuje hardware (bezpečnost, stabilita) ● aplikace nemají přímý přístup k HW ● grafika vyžaduje extrémní rychlost ● zprostředkování grafických operací jádrem „zdržuje“ ● proto je vyžadován „přímý“ přístup procesu k HW – proces musí mít administrátorská oprávnění – vzniká riziko ztráty stability a otázka bezpečnosti ● ve Windows grafický subsystém v jádře ● zvýšíme rychlost, omezíme modularitu a obecnost

Unixové řešení ● máme jádro ovládající TXT režim ● nastavíme pozici (25×80), vypíšeme znak ● grafiku vyřešíme jako aplikaci ●

X Window System ● 1983 – MIT (současné označení X11, X11R6) ● navazuje na W, navíc asynchronní komunikace ● model klient (aplikace) – server (ovládá HW) – rozšiřitelný komunikační protokol (zpětná kompatibilita) – aplikace instruuje server, co má vykreslit ● kompletně řešeno v uživatelském prostoru ● výborná přenositelnost, univerzálnost ● problematická rychlost (ovládání HW není v jádře) ● modulární systém ● X Server, správce oken, panel → zaměnitelné

X.org ● 2004 ● XFree86 mění licenci ● X.org přebírá poslední kódy a iniciativu – velký zájem tvůrců distribucí Linuxu – tím opuštěno XFree86 ● modulární stavba – X Server, ovladače, knihovny, další programy ● v současnosti – plně implementována 2D akcelerace – open source implementace 3D akcelerace ● Intel, ATI (nVidia se neúčastní, ale projekt Nouveau)

Řešení v Linuxu ● nutnost unifikace RAM a VideoRAM ● správce paměti v OS i v ovladači grafiky → kolize ● TTM v Linuxu spolu s DRI2, Gallium3D a KMS – nezbývá, než vpustit grafické funkce do jádra – jádro nastaví rozlišení a zveřejní rozhraní (DRI) – i textová konzole je nyní „grafická“ – při přepínání GUI a TXT se nemění grafický režim ● X server nepotřebuje práva roota – zvýšení bezpečnosti na úkor komplexity jádra