UNIX 14. Grafický subsystém

Prezentace na téma: "UNIX 14. Grafický subsystém"— Transkript prezentace:

1 UNIX 14. Grafický subsystém
Obsah: VGA, VESA, ovladače tvorba obrazu GPU, akcelerace, vztah k jádru 3D, OpenGL, LLVM správce oken Xlib, KDE, GNOME, freedesktop.org © Milan Keršláger

2 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)

3 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 dnes standard pro PC (de fakto) SVGA (1987) – IBM zvýšení rozlišení 800×600, 1024×768, ...

4 VGA Video Graphics Array maximálně 640×480@60Hz, 256 barev
základem textový režim MDA, až 512 znaků dodnes nejnižší a spolehlivý základ po resetu je grafická karta v textovém VGA rozlišení SVGA (Super VGA) VESA standard v roce 1989, též jako XGA výrobci vlastní další rozšíření → nekompatibility už moc nevadilo, protože ve Windows je ovladač na rozdíl od DOS aplikací již univerzální GDI API

5 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

6 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

7 Vytvoření obrazu grafická karta má svoji paměť (VideoRAM)
vyhrazená → paměť pouze pro graf. kartu sdílená → vyhrazená část operační paměti RAM zobrazení např × 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 = bitů = 3 MB volná paměť obsahuje bitmapy fontů, skrytá okna... urychlení vykreslování obrazu → akcelerace

8 Tvorba obrazu Video RAM Aplikace Monitor X server Grafický čip

9 GPU grafický procesor na videokartě
původně specializovaný obvod pro 2D grafiku dnes obdoba procesoru v počítači orientován na vektorové výpočty provádí 3D výpočty tj. modelování prostorové scény a převod do 2D obrazu dnes snaha využít jeho výpočetní potenciál není jednoduché zapřáhnout odlišný procesor specializované API pro X Window System offload dékódování video streamu: XvMC, VA API, VDPAU, ... podobně DxVA od Microsoftu pro Windows

10 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 pohybující se postavička ve hře, vyskakování menu 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č...

11 3D akcelerace 2D akcelerace už dnes zastaralá
GPU vytváří 2D 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í...

12 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 i akcelerované funkce v HW karty

13 MESA 3D multiplatformní implementace OpenGL
open source software, knihovna 3D funkcí všechny funkce řešeny softwarově (CPU) pokud je funkce přítomna v GPU, Mesa ji použije spolupracuje s DRI (Direct Rendering Interface) v jádře Linuxu plně implementováno OpenGL 2.1 částečně OpenGL 3 a 4 (jen některá rozšíření) využívá se v projektu X.org X,org je implementace grafického uživatelského prostředí X.org použit v Linuxu, BSD systémy, ale i Mac OS X

14 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

15 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

16 LLVM původně „Low Level Virtual Machine“
dnes obecný překladač, optimalizátor v Galium3D se používá pro shadery vertex, pixel a geometry shader modif. vrcholu, přidávání/odebírání vrcholů, aplikace textur GPU řízený mikroprogramem (každý čip má svůj) jde tedy o offload z CPU na GPU při výpočtu 3D scény programátor řeší problém obecně LLVM přeloží a optimalizuje pro konkrétní GPU OpenGL Shading Language (GLSL, GLslang) někdy je kód předem připraven v kódu ale nesmí být nebezpečné operace → dekompilace

17 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

18 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

19 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

20 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

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

22 X Server dnes se v Linuxu používá implementace „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

23 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) protokol je rozšiřitelný xrandr (změny rozlišení, rotace, … bez restartu) 3D rozšíření

24 Správce oken Window Manager (WM)
speciální program → umístění a vhled oken v GUI řeší dekoraci oken, aktivní okno, přenos do popředí/pozadí, překryv oken, přesun, zvětšení/zmenšení, zmenšení okna do ikony (nelze v MS Windows) a další (myš, komunikace, ...) kompozitní správce oken jednotlivá okna, pozadí, plocha jsou v (grafické) paměti odděleně správce oken instruuje GPU o složení obrazu tj. průhlednost, vlnění, zakřivení → GPU

25 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, ...)

26 Ú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ší...

27 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 též v projektu

28 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 zapojeno do projektu dnes licence GPL

29 freedesktop.org od roku 2000, zastřešuje více projektů
pro unixová desktopová prostředí zejména graf. prostředí GNOME, KDE, Xfce další projekty: DRI, Mesa – 3D akcelerace, Cairo – vektorová knihovna X.org server, D-Bus Gstreamer – multimediální framework XCB by mělo nahradit Xlib Drag-and-drop – DaD není v X stále jednotné :-( shrnutí důležitých komponent, standardizace vývojářské prostředí (Git, Bugzilla, WWW, ...)