UNIX 14. Grafický subsystém © Milan Keršláger 2018/9/8 http://www.pslib.cz/ke/slajdy http://creativecommons.org/licenses/by-nc-nd/3.0/

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ě 640×480@60Hz, 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ř. 1024 × 768, 32bpp 1 bod na 32 bitů → 232 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 = 25165824 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 clipping, off screen caching rychlé překrývání objektů, fonty připravené ve videoRAM čára, obdélník, trojůhelník, kružnice, výseč...

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 Aplikace Galium3D + DRI Ovladače: DRM + DRM_karta Galium3D a DRM jsou obecné knihovny DRI a DRM_karta řeší HW závislosti Mesa je 3D knihovna → SW rasterizer pro OpenGL Aplikace Mesa (knihovna) Galium3D + DRI Jádro OS Ovladače: DRM + DRM_karta Grafická karta Hardware

Direct3D ve Windows Aplikace GDI Direct3D Ovladač Grafická karta GDI – vykreslování oken, widgetů podobně jako GTK+, Qt nebo Xlib Aplikace GDI Direct3D Knihovny Ovladač Jádro OS Grafická karta 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í (root) vzniká riziko ztráty stability a otázka bezpečnosti ve Windows je grafický subsystém v jádře zvýšíme rychlost, omezíme modularitu a obecnost

Oddělené ř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 server → ovládá HW velmi přenositelné řešení, nevyžaduje zásahy do jádra souboj X serveru a jádra o RAM a videoRAM přepínání textového a grafického režimu též problém usínání a probouzení kdo probudí kartu? X server ještě neběží, jádro už ano... v současnosti se ukazuje nutnost jádro rozšířit v Linuxu KMS, TTM → root-less X

Grafika v jádře 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 přístup ke GPU přes filtr jádra → rychlé kontroly

Schéma komunikace Aplikace Window manager X server Grafická karta X protokol Window manager X server Grafická karta

X server dnes se v Linuxu používá X.org modulární stavba jeden univerzální X server ovladače grafických karet jako moduly ATI a nVidia mají binární ovladače bez zdrojových kódů pro většinu HW existují open source ovladače bez nutnosti konfigurace může být /etc/X11/xorg.conf, /etc/X11/xorg.conf.d/ používá se jen ve speciálních případech vypínání některých akcelerací při problémech se stabilitou speciální konfigurace v případě selhání autodetekce logování do /var/log/Xorg.0.log

X protokol komunikace mezi aplikacemi a X serverem model klient – server zajišťuje nezávislost na zařízení umožňuje použití sítě asynchronní komunikace není nutné čekat na dokončení požadavku jsou implementovány fronty (u serveru i klienta)

xdm, gdm, kdm, ... X Display Manager vytváří úvodní přihlašovací obrazovku po přihlášení se vytvoří „session“ prostředí se spuštěnými programy pod ID uživatele vše spustí pomocí sady skriptů uloženy v /etc/X11/xdm dvě hlavní komponenty prostředí: Window Manager – správce oken vytváří dekorace oken, změny pozice, velikosti, překrývání, … panel lišta s menu, seznamem oken, aplety (hodiny, Skype, ...)

Úloha knihoven v GUI Xlib základní knihovna pro X Window system je velmi primitivní, v programu se používá obtížně program ↔ Xlib ↔ X protokol ↔ X server další knihovny implementují „widget toolkit“ umí vykreslit základní prvky pro GUI nadstavba nad Xlib GTK+ – původně pro GIMP → rozhraní GNOME Qt – Trolltech → rozhraní KDE a další...

KDE nad Qt knihovnami („kjůt“) desktopové prostředí Qt naprogramováno v C++ (objektově) Linux, Windows, Mac, aplikace mohou být v jakémkoliv jazyce, i skripty všude je unifikované rozhraní i aplikace pro uživatele vše vypadá stejně vytváří stejný dojem, jako Microsoft Windows http://www.kde.org zapojeno do projektu http://www.freedesktop.org dnes licence GPL

GNOME knihovny GTK+ desktopové prostředí GTK+ naprogramováno v jazyce C, ale je objektové inspirace Mac OS X od začátku licence GPL soustředí se na vytvoření vývojového prostředí aplikace jsou samostatné, nestejné, nepatří pod projekt http://www.gnome.org též v projektu http://www.freedesktop.org