UNIX 14. Grafický subsystém

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

1 UNIX 14. Grafický subsystém
© Milan Keršláger 2018/9/8

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 maximálně 256 barev základem textový režim MDA, až 512 znaků stala se standardem v PC

4 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

5 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

6 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ů → 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

7 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č...

8 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í...

9 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

10 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

11 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

12 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

13 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

14 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

15 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

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

17 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

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

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

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

21 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

22 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