Operační systémy Grafický subsystém © Milan Keršláger Obsah:

Historie ● 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 před zobrazením transformuje – 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

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“ ● vyžadován „přímý“ přístup k HW – vyžaduje změnu přístupu k oddělení SW a HW ● 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

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 č GD I Direct3 D Aplikac e ● GDI – vykreslování oken, widgetů ● podobně jako GTK+, Qt nebo Xlib Jádro OS Knihovny Hardware