Správce přímého vykreslování - Direct Rendering Manager - Wikipedia

Správce přímého vykreslování
Původní autořikernel.org & freedesktop.org
Vývojářikernel.org & freedesktop.org
NapsánoC
Typ
Licence
webová stránkadri.freedesktop.org/ wiki/ DRM
Nesmí být zaměňována s Správa digitálních práv.

The Správce přímého vykreslování (DRM) je subsystémem Linuxové jádro odpovědný za propojení s GPU moderní grafické karty. DRM vystavuje API že uživatelský prostor programy mohou použít k odesílání příkazů a dat do GPU a provádění operací, jako je konfigurace nastavení režimu displeje. DRM byl poprvé vyvinut jako jádrový prostor složka X Server Infrastruktura přímého vykreslování,[1] ale od té doby to bylo používáno jinými alternativami grafického zásobníku, jako je Wayland.

Programy v uživatelském prostoru mohou pomocí příkazu DRM API ovládat GPU hardwarově akcelerováno 3D vykreslování a dekódování videa, stejně jako Výpočet GPGPU.

Přehled

The Linuxové jádro už měl API volala fbdev, který se používá ke správě framebuffer a grafický adaptér,[2] ale nemohlo to být použito k řešení potřeb moderního 3D akcelerovaného GPU - video hardware na bázi. Tato zařízení obvykle vyžadují nastavení a správu fronty příkazů jejich vlastní paměť odesílat příkazy do GPU a také vyžadovat správu vyrovnávacích pamětí a volného místa v této paměti.[3] Zpočátku programy v uživatelském prostoru (například X Server ) přímo spravovaly tyto zdroje, ale obvykle se chovaly, jako by byly jediné, které k nim mají přístup. Když se dva nebo více programů pokusilo ovládat stejný hardware současně a nastavovat jeho zdroje každý svým vlastním způsobem, většinou skončily katastroficky.[3]

Přístup ke grafické kartě bez DRM
Bez DRM
Přístup ke grafické kartě s DRM
S DRM
DRM umožňuje více programům souběžný přístup k 3D grafické kartě, aby nedocházelo ke kolizím

Správce přímého vykreslení byl vytvořen, aby umožnil více programům kooperativně využívat video hardwarové prostředky.[4] DRM získá exkluzivní přístup k GPU a je zodpovědný za inicializaci a údržbu příkazové fronty, paměti a jakéhokoli jiného hardwarového prostředku. Programy, které chtějí použít GPU, odesílají požadavky do DRM, které funguje jako arbitr a dbá na to, aby nedocházelo ke konfliktům.

Rozsah DRM byl v průběhu let rozšířen tak, aby pokrýval více funkcí dříve zpracovávaných programy v uživatelském prostoru, jako je správa framebufferů a nastavení režimu, objekty sdílení paměti a synchronizace paměti.[5][6] Některé z těchto expanzí dostaly konkrétní názvy, například Správce grafického spuštění (GEM) nebo nastavení režimu jádra (KMS) a terminologie převažuje, když se konkrétně zmiňuje o funkcích, které poskytují. Ale jsou to opravdu části celého subsystému DRM jádra.

Trend zahrnutí dvou GPU do počítače - diskrétní GPU a integrovaný - vedl k novým problémům, jako je Přepínání GPU to také bylo potřeba vyřešit na DRM vrstvě. Aby odpovídal Nvidia Optimus technologie DRM byla vybavena schopnostmi vykládání GPU, tzv. PRIME.[7]

Softwarová architektura

Proces využívající Direct Rendering Manager linuxového jádra pro přístup ke 3D akcelerované grafické kartě

Správce přímého vykreslování sídlí v prostor jádra, takže programy v uživatelském prostoru musí používat jádro systémová volání požádat o její služby. DRM však nedefinuje vlastní přizpůsobená systémová volání. Místo toho následuje Unix princip „všechno je soubor "vystavit GPU prostřednictvím prostoru názvů souborového systému pomocí soubory zařízení pod / dev hierarchie. Každá GPU detekovaná pomocí DRM se označuje jako a Zařízení DRMa soubor zařízení / dev / dri / kartaX (kde X je pořadové číslo) je vytvořeno pro propojení s ním.[8][9] Programy v uživatelském prostoru, které chtějí mluvit s GPU, musí otevřeno tento soubor a použít ioctl hovory ke komunikaci s DRM. Různé ioctls odpovídají různým funkcím DRM API.

A knihovna volala libdrm byl vytvořen za účelem usnadnění rozhraní programů v uživatelském prostoru se subsystémem DRM. Tato knihovna je pouze a obal který poskytuje a funkce napsáno v C pro každý ioctl DRM API, stejně jako konstanty, struktury a další pomocné prvky.[10] Použití libdrm nejenže nevystavuje rozhraní jádra přímo aplikacím, ale představuje obvyklé výhody opětovné použití a sdílení kódu mezi programy.

Direct Rendering Manager architecture details: DRM core and DRM driver (including GEM and KMS) interfaced by libdrm

DRM se skládá ze dvou částí: obecné „jádro DRM“ a specifické („ovladač DRM“) pro každý typ podporovaného hardwaru.[11] Jádro DRM poskytuje základní rámec, kde se mohou zaregistrovat různé ovladače DRM, a také poskytuje uživatelskému prostoru minimální sadu ioctls se společnou funkcí nezávislou na hardwaru.[8] Ovladač DRM na druhé straně implementuje hardwarově závislou část API, specifickou pro typ GPU, který podporuje; měl by poskytovat implementaci zbývajících ioctls, které nejsou pokryty jádrem DRM, ale může také rozšířit API a nabídnout další ioctls s extra funkcemi dostupnými pouze na takovém hardwaru.[8] Když konkrétní ovladač DRM poskytuje vylepšené API, libdrm v uživatelském prostoru je také rozšířen o další knihovnu libdrm-Řidič které může uživatelský prostor využít k propojení s dalšími ioctly.

API

Jádro DRM exportuje několik rozhraní do aplikací v uživatelském prostoru, které jsou obecně určeny k použití prostřednictvím odpovídajících libdrm funkce obálky. Ovladače navíc exportují rozhraní specifická pro zařízení pro použití ovladači v uživatelském prostoru a aplikacemi podporujícími zařízení ioctls a sysfs soubory. Mezi externí rozhraní patří: mapování paměti, správa kontextu, DMA operace, AGP řízení, vblank řízení, správa oplocení, správa paměti a správa výstupu.

DRM-Master a DRM-Auth

V rozhraní DRM API existuje několik operací (ioctls), které musí být z bezpečnostních důvodů nebo pro problémy se souběžností omezeny, aby mohly být použity jedním procesem v uživatelském prostoru na zařízení.[8] Aby bylo možné implementovat toto omezení, DRM omezuje, aby takovéto ioctls byly vyvolány pouze procesem považovaným za „pána“ zařízení DRM, obvykle DRM-Master. Pouze jeden ze všech procesů, které mají uzel zařízení / dev / dri / kartaX otevřený bude mít svůj popisovač souboru označen jako hlavní, konkrétně první volající na SET_MASTER ioctl. Jakýkoli pokus o použití jednoho z těchto omezených ioctlů, aniž by byl DRM-Master, vrátí chybu. Proces se může také vzdát své hlavní role - a nechat jej získat jiným procesem - voláním DROP_MASTER ioctl.

The X Server - nebo jakýkoli jiný zobrazovací server —Je běžně proces, který získává stav DRM-Master v každém zařízení DRM, které spravuje, obvykle při otevření příslušného uzlu zařízení během jeho spouštění a udržuje tato oprávnění pro celou grafickou relaci, dokud nedokončí nebo nezemře.

U zbývajících procesů v uživatelském prostoru existuje další způsob, jak získat oprávnění k vyvolání některých omezených operací na volaném zařízení DRM DRM-Auth. Jedná se v zásadě o metodu ověřování proti zařízení DRM, aby se prokázalo, že tento proces má oprávnění DRM-Master k získání těchto oprávnění. Postup se skládá z:[12]:13

  • Klient získá jedinečný token - 32bitové celé číslo - ze zařízení DRM pomocí GET_MAGIC ioctl a předává jej do procesu DRM-Master jakýmkoli způsobem (obvykle nějakým způsobem IPC; například v DRI2 tady je DRI2Authenticate požadovat, aby kterýkoli X klient mohl poslat na X Server.[13])
  • Proces DRM-Master zase odešle token do zařízení DRM vyvoláním AUTH_MAGIC ioctl.
  • Zařízení uděluje zvláštní práva pro zpracování souboru procesu, jehož token ověření odpovídá přijatému tokenu z DRM-Master.

Správce grafického spuštění

Vzhledem k rostoucí velikosti videopaměť a rostoucí složitost grafických API, jako je OpenGL, strategie reinicializace stavu grafické karty u každého kontextový přepínač bylo příliš drahé a výkonné. Také moderní Linuxové pracovní plochy potřeboval optimální způsob sdílení vyrovnávacích pamětí mimo obrazovku s správce skládání. Tyto požadavky vedly k vývoji nových metod správy grafiky Nárazníky uvnitř jádra. The Správce grafického spuštění (GEM) se ukázala jako jedna z těchto metod.[6]

GEM poskytuje API s explicitním správa paměti primitiv.[6] Prostřednictvím GEM může program v uživatelském prostoru vytvářet, zpracovávat a ničit paměťové objekty žijící ve videopaměti GPU. Tyto objekty, nazývané „objekty GEM“,[14] jsou trvalé z pohledu programu uživatelského prostoru a není nutné je znovu načítat pokaždé, když program znovu získá kontrolu nad GPU. Když program v uživatelském prostoru potřebuje kus videopaměti (k uložení a framebuffer, textura nebo jakákoli jiná data požadovaná GPU[15]), požaduje přidělení ovladači DRM pomocí GEM API. Ovladač DRM sleduje použitou videopaměť a je schopen vyhovět požadavku, pokud je k dispozici volná paměť, vrací "popisovač" do uživatelského prostoru, aby dále odkazoval na přidělenou paměť v nadcházejících operacích.[6][14] GEM API také poskytuje operace k naplnění vyrovnávací paměti a k ​​jejímu uvolnění, když ji již není potřeba. Paměť z nevydaných popisovačů GEM se obnoví, když proces v uživatelském prostoru zavře zařízení DRM deskriptor souboru —Úmyslně nebo proto, že končí.[16]

GEM také umožňuje dva nebo více uživatelských prostor procesy pomocí stejného zařízení DRM (tedy stejného ovladače DRM) ke sdílení objektu GEM.[16] GEM popisovače jsou lokální 32bitová celá čísla jedinečná pro proces, ale opakovatelná v jiných procesech, proto nejsou vhodná pro sdílení. Co je potřeba, je globální jmenný prostor a GEM poskytuje jeden prostřednictvím použití globálních popisovačů zvaných Názvy klenotů. Název GEM odkazuje na jeden a pouze jeden objekt GEM vytvořený ve stejném zařízení DRM stejným ovladačem DRM pomocí jedinečné 32bitové verze celé číslo. GEM poskytuje operaci blikat získat název GEM z popisovače GEM.[16][12]:16 Proces pak může předat tento název GEM (32bitové celé číslo) jinému procesu pomocí libovolného IPC mechanismus k dispozici.[12]:15 Název GEM může proces příjemce použít k získání místního popisovače GEM směřujícího k původnímu objektu GEM.

Použití jmen GEM ke sdílení vyrovnávacích pamětí bohužel není bezpečné.[12]:16[17][18] Škodlivý proces třetí strany, který přistupuje ke stejnému zařízení DRM, by se mohl pokusit uhodnout název GEM vyrovnávací paměti sdílené dalšími dvěma procesy, jednoduše sondováním 32bitových celých čísel.[19][18] Jakmile je nalezen název GEM, je možné přistupovat k jeho obsahu a měnit jej, což porušuje důvěrnost a integrita informace o vyrovnávací paměti. Tato nevýhoda byla překonána později zavedením DMA-BUF podpora do DRM.

Dalším důležitým úkolem pro jakýkoli systém správy videopaměti kromě správy prostoru videopaměti je zpracování synchronizace paměti mezi GPU a CPU. Proud paměťové architektury jsou velmi složité a obvykle zahrnují různé úrovně mezipaměti pro systémovou paměť a někdy i pro videopaměť. Správci videopaměti by proto měli pracovat také s soudržnost mezipaměti zajistit konzistentnost dat sdílených mezi CPU a GPU.[20] To znamená, že interní zařízení pro správu videopaměti často velmi závisí na hardwarových detailech GPU a architektuře paměti, a proto jsou specifické pro ovladač.[21]

GEM byl původně vyvinut společností Intel inženýři, aby pro svůj ovladač i915 poskytli správce videopaměti.[20] The Intel GMA 9xx rodina jsou integrované GPU s architekturou Uniform Memory Architecture (UMA), kde GPU a CPU sdílejí fyzickou paměť, a neexistuje speciální VRAM.[22] GEM definuje "paměťové domény" pro synchronizaci paměti, a přestože jsou tyto paměťové domény nezávislé na GPU,[6] jsou speciálně navrženy s ohledem na paměťovou architekturu UMA, takže jsou méně vhodné pro jiné paměťové architektury, jako jsou ty se samostatnou VRAM. Z tohoto důvodu se ostatní ovladače DRM rozhodli vystavit programům uživatelského prostoru rozhraní GEM API, ale interně implementovali jiného správce paměti, který lépe vyhovuje jejich konkrétnímu hardwaru a architektuře paměti.[23]

Rozhraní GEM API také poskytuje ioctls pro řízení toku provádění (vyrovnávací paměti příkazů), ale jsou specifické pro Intel, které se používají s Intel i915 a novějšími GPU.[6] Žádný jiný ovladač DRM se nepokusil implementovat jakoukoli část GEM API nad rámec specifických ioctls pro správu paměti.

Mapy překladových tabulek

Mapy překladových tabulek (TTM) je název generického správce paměti pro GPU, který byl vyvinut před GEM.[5][14] Byl speciálně navržen pro správu různých typů paměti, ke kterým může GPU přistupovat, včetně vyhrazené Video RAM (běžně instalovaný na grafické kartě) a systémová paměť přístupné přes Jednotka správy I / O paměti volal Tabulka přemapování grafické adresy (GART).[5] TTM by měl také zpracovávat části video RAM, které nejsou přímo adresovatelné CPU, a dělat to s nejlepším možným výkonem, vzhledem k tomu, že grafické aplikace v uživatelském prostoru obvykle pracují s velkým množstvím video dat. Další důležitou věcí bylo udržovat konzistenci mezi různými vzpomínkami a zapojenými cache.

Hlavním konceptem TTM jsou „vyrovnávací objekty“, oblasti video paměti, které musí být v určitém okamžiku adresovatelné GPU.[5] Když chce grafická aplikace v uživatelském prostoru získat přístup k určitému objektu vyrovnávací paměti (obvykle k jeho naplnění obsahem), může TTM vyžadovat jeho přemístění na typ paměti adresovatelný CPU. Další přemístění - nebo operace mapování GART - se mohou stát, když GPU potřebuje přístup k objektu vyrovnávací paměti, ale ještě není v adresním prostoru GPU. Každá z těchto operací přemístění musí zpracovat všechny související problémy s daty a koherencí mezipaměti.[5]

Dalším důležitým konceptem TTM je ploty. Ploty jsou v podstatě mechanismem pro správu souběžnosti mezi CPU a GPU.[24] Plot sleduje, když objekt vyrovnávací paměti již GPU nepoužívá, obecně k upozornění na jakýkoli proces v uživatelském prostoru s přístupem k němu.[5]

Skutečnost, že se TTM pokusila vhodným způsobem spravovat všechny druhy paměťových architektur, včetně těch s vyhrazenou VRAM a bez ní, a poskytnout všechny myslitelné funkce ve správci paměti pro použití s ​​jakýmkoli typem hardwaru, vedla k příliš složitému řešení s API mnohem větším, než je potřeba.[24][14] Někteří vývojáři DRM si mysleli, že by to nesedělo s žádným konkrétním ovladačem, zejména s API. Když se GEM ukázal jako jednodušší správce paměti, jeho API bylo upřednostňováno před TTM. Někteří vývojáři ovladačů ale usoudili, že přístup TTM byl vhodnější pro diskrétní grafické karty s vyhrazenou grafickou pamětí a IOMMU, proto se rozhodli použít TTM interně, přičemž vystavili své objekty vyrovnávací paměti jako objekty GEM a podporovali tak rozhraní GEM API.[23] Příklady současných ovladačů používajících TTM jako správce interní paměti, ale poskytujících GEM API, jsou ovladače Radeon pro grafické karty AMD a novinka ovladač pro grafické karty NVIDIA.

Sdílení vyrovnávací paměti DMA a PRIME

The DMA Buffer Sharing API (často zkráceně DMA-BUF) je a Linuxové jádro vnitřní API navržen tak, aby poskytoval obecný mechanismus sdílení DMA vyrovnávací paměti mezi více zařízeními, případně spravované různými typy ovladačů zařízení.[25][26] Například a Video4Linux zařízení a zařízení grafického adaptéru by mohly dosáhnout vyrovnávacích pamětí prostřednictvím DMA-BUF nulová kopie dat video proudu vytvářeného prvním a spotřebovaným druhým. Libovolný Linux ovladač zařízení může implementovat toto API jako vývozce, jako uživatel (spotřebitel) nebo obojí.

Tato funkce byla poprvé využita v DRM k implementaci PRIME, řešení pro Vykládání GPU který používá DMA-BUF ke sdílení výsledných framebufferů mezi DRM ovladači diskrétního a integrovaného GPU.[27]:13 Důležitou vlastností DMA-BUF je, že sdílená vyrovnávací paměť je prezentována v uživatelském prostoru jako deskriptor souboru.[14][12]:17 Pro vývoj PRIME byly do rozhraní DRM API přidány dva nové ioctly, jeden pro převod místního popisovače GEM na deskriptor souboru DMA-BUF a druhý pro přesně opačnou operaci.

Tyto dva nové ioctly byly později znovu použity jako způsob, jak opravit inherentní bezpečnost sdílení vyrovnávací paměti GEM.[12]:17 Na rozdíl od názvů GEM nelze deskriptory souborů uhodnout (nejedná se o globální jmenný prostor) a operační systémy Unix poskytují bezpečný způsob, jak je předat Unixový socket domény pomocí sémantiky SCM_RIGHTS.[14][28]:11 Proces, který chce sdílet objekt GEM s jiným procesem, může převést svůj místní popisovač GEM na deskriptor souboru DMA-BUF a předat jej příjemci, který zase může získat vlastní popisovač GEM z přijatého deskriptoru souboru.[12]:16 Tuto metodu používá DRI3 ke sdílení vyrovnávacích pamětí mezi klientem a X serverem[29] a také Wayland.

Nastavení režimu jádra

V uživatelském prostoru musí být „master DRM“, tento program má výhradní přístup ke KMS.

Pro správnou funkci musí grafická karta nebo grafický adaptér nastavit a režimu —Kombinace Rozlišení obrazovky, barevná hloubka a Obnovovací frekvence —To je v rozsahu hodnot podporovaných samotnou a připojenou zobrazit obrazovku. Tato operace se nazývá nastavení režimu,[30] a obvykle to vyžaduje surový přístup ke grafickému hardwaru - tj. schopnost zapisovat do určitých registrů grafické karty.[31][32] Před zahájením používání musí být provedena operace nastavení režimu framebuffer, a také v případě, že je požadována změna režimu aplikací nebo uživatelem.

V počátcích byly za provádění operací nastavení režimu odpovědné také programy uživatelského prostoru, které chtěly používat grafický framebuffer,[3] a proto potřebovali běžet s privilegovaným přístupem k video hardware. V operačních systémech typu Unix X Server byl nejvýznamnějším příkladem a jeho implementace nastavení režimu žila v Ovladač DDX pro každý konkrétní typ grafické karty.[33] Tento přístup, později označovaný jako Nastavení režimu uživatelského prostoru nebo UMS,[34][35] představuje několik problémů.[36][30] Porušuje nejen izolaci, kterou by operační systémy měly poskytovat mezi programy a hardwarem, což zvyšuje stabilitu i bezpečnost, ale může také ponechat grafický hardware v nekonzistentním stavu, pokud se dva nebo více programů v uživatelském prostoru pokusí provést nastavení režimu na stejný čas. Aby se těmto konfliktům zabránilo, stal se X Server v praxi jediným programem uživatelského prostoru, který prováděl operace nastavení režimu; zbývající programy uživatelského prostoru spoléhaly na X Server, že nastaví vhodný režim a zvládne jakoukoli další operaci zahrnující nastavení režimu. Zpočátku bylo nastavení režimu prováděno výhradně během procesu spouštění X Serveru, ale později X Server získal schopnost to dělat za běhu.[37] Rozšíření XFree86-VidModeExtension bylo představeno v XFree86 3.1.2 umožnit jakýkoli požadavek X klienta modelka (rozlišení) se změní na X Server.[38][39] Rozšíření VidMode bylo později nahrazeno obecnějším XRandR rozšíření.

Nebyl to však jediný kód provádějící nastavení režimu v a Linux Systém. Během procesu zavádění systému musí jádro Linuxu nastavit minimální textový režim pro virtuální konzole (na základě standardních režimů definovaných VESA BIOS rozšíření).[40] Také Ovladač framebufferu jádra Linuxu obsažený kód pro nastavení režimu pro konfiguraci zařízení framebuffer.[2] Aby nedocházelo ke konfliktům při nastavování režimů, Server XFree86 - a později X.Org Server —Řešil případ, kdy uživatel přešel z grafického prostředí na text virtuální konzole uložením jeho stavu nastavení režimu a jeho obnovením, když se uživatel přepne zpět na X.[41] Tento proces způsobil při přechodu nepříjemné blikání a také může selhat, což vedlo k poškozenému nebo nepoužitelnému zobrazení výstupu.[42]

Přístup k nastavení režimu uživatelského prostoru také způsobil další problémy:[43][42]

  • The pozastavit / obnovit proces musí při obnovení předchozího režimu spoléhat na nástroje uživatelského prostoru. Jedna jediná chyba nebo selhání jednoho z těchto programů by mohla systém nechat bez funkčního zobrazení kvůli nesprávné konfiguraci sady režimů, a proto nepoužitelná.
  • Bylo také nemožné, aby jádro zobrazovalo chybové nebo ladicí zprávy, když byla obrazovka v grafickém režimu - například když běžel X - protože jediné režimy, o kterých jádro vědělo, byly standardní textové režimy VESA BIOS.
  • Naléhavějším problémem bylo rozšíření grafických aplikací obcházejících X Server a vznik dalších alternativ grafického zásobníku k X, což ještě více rozšířilo duplikaci kódu pro nastavení režimu v celém systému.

K vyřešení těchto problémů byl kód pro nastavení režimu přesunut na jedno místo uvnitř jádra, konkrétně do existujícího modulu DRM.[36][37][44][42][43] Pak by každý proces - včetně X Serveru - měl být schopen jádru přikázat provádět operace nastavení režimu a jádro by zajistilo, že souběžné operace nebudou mít za následek nekonzistentní stav. Bylo voláno nové API jádra a kód přidaný do modulu DRM k provádění těchto operací nastavení režimu Nastavení režimu jádra (KMS).[30]

Nastavení režimu jádra poskytuje několik výhod. Nejpravděpodobnější je samozřejmě odstranění duplicitního kódu pro nastavení režimu, a to jak z jádra (linuxová konzole, fbdev), tak z uživatelského prostoru (ovladače X Server DDX). KMS také usnadňuje psaní alternativních grafických systémů, které nyní nepotřebují implementovat vlastní kód pro nastavení režimu.[42][43] Poskytnutím centralizované správy režimu řeší KMS problémy s blikáním při přepínání mezi konzolou a X a také mezi různými instancemi X (rychlé přepínání uživatelů).[41][44] Jelikož je k dispozici v jádře, lze jej použít také na začátku procesu spouštění, což šetří blikání způsobené změnami režimu v těchto raných fázích.

Skutečnost, že KMS je součástí jádra, umožňuje používat zdroje dostupné pouze v prostoru jádra, jako je přerušení.[45] Například obnovení režimu po procesu pozastavení / obnovení značně zjednodušuje správu samotným jádrem a mimochodem zlepšuje zabezpečení (žádné další nástroje uživatelského prostoru vyžadující oprávnění root). Jádro také umožňuje hotplug nových zobrazovacích zařízení snadno řeší dlouhodobý problém.[45] Nastavení režimu také úzce souvisí se správou paměti - protože framebuffery jsou v zásadě vyrovnávací paměti - proto se velmi doporučuje těsná integrace se správcem grafické paměti. To je hlavní důvod, proč byl kód pro nastavení režimu jádra začleněn do DRM, a nikoli jako samostatný subsystém.[44]

Aby se zabránilo narušení zpětné kompatibility rozhraní DRM API, je jako další poskytováno nastavení režimu jádra funkce ovladače některých ovladačů DRM.[46] Jakýkoli ovladač DRM se může rozhodnout poskytnout DRIVER_MODESET příznak, když se zaregistruje u jádra DRM, což znamená, že podporuje KMS API.[8] Ovladače, které implementují nastavení režimu jádra, se často nazývají Ovladače KMS jako způsob, jak je odlišit od starších - bez KMS - ovladačů DRM.

KMS byl přijat do takové míry, že určité ovladače, kterým chybí 3D akcelerace (nebo pro které prodejce hardwaru nechce vystavit nebo je implementovat), přesto implementují KMS API bez zbytku DRM API.

Model zařízení KMS

KMS modeluje a spravuje výstupní zařízení jako sérii abstraktních hardwarových bloků, které se běžně vyskytují na výstupním kanálu displeje a řadič displeje. Jedná se o tyto bloky:[47]

  • CRTC: každý CRTC (od CRT Ovladač[48][33]) představuje skluz motoru řadiče displeje, směřující k a vyrovnávací vyrovnávací paměť (framebuffer ).[47] Účelem CRTC je číst pixelová data aktuálně ve vyrovnávací paměti scanout a generovat z nich časovací signál režimu videa s pomocí a PLL obvod.[49] Počet dostupných CRTC určuje, kolik nezávislých výstupních zařízení může hardware současně zpracovat, aby bylo možné je použít vícehlavý je vyžadována konfigurace alespoň jednoho CRTC na zobrazovací zařízení.[47] Mohou pracovat také dva nebo více CRTC klonový režim pokud skenují ze stejného framebufferu a posílají stejný obraz na několik výstupních zařízení.[49][48]
  • Konektory: konektor představuje místo, kde řadič displeje odesílá video signál z operace scanout, která se má zobrazit. Koncept KMS konektoru obvykle odpovídá fyzickému konektoru (VGA, DVI, FPD-Link, HDMI, DisplayPort, S-Video ...) v hardwaru, kde je výstupní zařízení (monitor, notebook panel, ...) je trvale nebo lze dočasně připojit. Informace týkající se aktuálního fyzicky připojeného výstupního zařízení - například stav připojení, EDID data, DPMS stav nebo podporované režimy videa - je také uložen v konektoru.[47]
  • Kodéry: řadič displeje musí kódovat časovací signál video režimu z CRTC ve formátu vhodném pro zamýšlený konektor.[47] Kodér představuje hardwarový blok schopný provádět jedno z těchto kódování. Příklady kódování - pro digitální výstupy - jsou TMDS a LVDS; pro analogové výstupy jako VGA a TV výstup, charakteristický DAC bloky se obvykle používají. Konektor může přijímat signál pouze z jednoho kodéru najednou,[47] a každý typ konektoru podporuje pouze některá kódování. Mohou také existovat další fyzická omezení, kterými není každý CRTC připojen ke každému dostupnému kodéru, což omezuje možné kombinace konektoru CRTC-kodér.
  • Letadla: letadlo není hardwarový blok, ale paměťový objekt obsahující vyrovnávací paměť, ze které je napájen scanout engine (CRTC). Letadlo, které drží framebuffer se nazývá primární rovinaa ke každému CRTC musí být přidružen jeden,[47] protože je to zdroj pro CRTC pro určování video režimu - rozlišení displeje (šířka a výška), velikost pixelu, formát pixelu, obnovovací frekvence atd. CRTC může mít také kurzorové roviny přidružené k tomu, pokud řadič displeje podporuje překrytí hardwarových kurzorů, nebo sekundární letadla pokud je schopen skenovat z dalších hardwarové překryvy a skládat nebo míchat „za běhu“ finální obraz odeslaný do výstupního zařízení.[33]

Atomový displej

V posledních letech stále přetrvává úsilí přinést atomicita k některým běžným operacím týkajícím se KMS API, konkrétně k nastavení režimu a obracející stránku operace.[33][50] Toto vylepšené rozhraní KMS API se nazývá Atomový displej (dříve známý jako nastavení atomového režimu a atomový nebo jaderný pageflip).

Účelem nastavení atomového režimu je zajistit správnou změnu režimu ve složitých konfiguracích s více omezeními tím, že se vyhnete přechodným krokům, které by mohly vést k nekonzistentnímu nebo neplatnému stavu videa;[50] vyhne se také rizikovým stavům videa, když je třeba vrátit zpět neúspěšný proces nastavení režimu („rollback“).[51]:9 Atomový režim umožňuje předem zjistit, zda je vhodná určitá konfigurace konkrétního režimu, a to poskytnutím možností testování režimu.[50] Když je testován atomový režim a potvrzena jeho platnost, může být použit s jednou nedělitelnou (atomovou) spáchat úkon. Testovací i potvrzovací operace jsou poskytovány stejnou novinkou ioctl s různými příznaky.

Převrácení atomové stránky na druhé straně umožňuje aktualizovat více rovin na stejném výstupu (například primární rovinu, rovinu kurzoru a možná i některá překrytí nebo sekundární roviny) všechny synchronizované ve stejné VBLANK interval, zajišťující správné zobrazení bez trhání.[51]:9,14[50] Tento požadavek je obzvláště relevantní pro mobilní a integrované řadiče zobrazení, které mají tendenci používat více letadel / překrytí k úspoře energie.

Nové atomové API je postaveno na starém KMS API. Používá stejný model a objekty (CRTC, kodéry, konektory, roviny, ...), ale s rostoucím počtem vlastností objektů, které lze upravit.[50] Atomový postup je založen na změně příslušných vlastností k vytvoření stavu, který chceme otestovat nebo potvrdit. Vlastnosti, které chceme upravit, závisí na tom, zda chceme provést nastavení režimu (většinou vlastnosti CRTC, kodéry a konektory) nebo převrácení stránky (obvykle vlastnosti rovin). Ioctl je stejný pro oba případy, rozdílem je seznam vlastností předávaných s každým z nich.[52]

Vykreslit uzly

V původním rozhraní DRM API je zařízení DRM / dev / dri / kartaX se používá jak pro privilegované (nastavení režimů, další ovládání zobrazení), tak pro privilegované (vykreslování, GPGPU operace).[9] Z bezpečnostních důvodů vyžaduje otevření přidruženého souboru zařízení DRM speciální oprávnění „ekvivalentní oprávněním root“.[53] To vede k architektuře, kde pouze některé spolehlivé programy uživatelského prostoru (server X, grafický skladatel, ...) mají plný přístup k API DRM, včetně privilegovaných částí, jako je API sady režimů. Zbylé aplikace v uživatelském prostoru, které chtějí vykreslit nebo provést výpočty GPGPU, by měl vlastník zařízení DRM („DRM Master“) udělit pomocí speciálního ověřovacího rozhraní.[54] Poté mohou ověřené aplikace vykreslovat nebo provádět výpočty pomocí omezené verze rozhraní DRM API bez privilegovaných operací. Tento design představuje vážné omezení: vždy musí existovat běžící grafický server (X Server, skladatel Wayland, ...), který bude fungovat jako DRM-Master zařízení DRM, aby bylo možné povolit použití jiných programů v uživatelském prostoru zařízení, a to i v případech, kdy se nejedná o grafický displej, jako jsou výpočty GPGPU.[53][54]

Koncept „renderovacích uzlů“ se pokouší tyto scénáře vyřešit rozdělením API uživatelského prostoru DRM na dvě rozhraní - jedno privilegované a jedno neprivilegované - a pro každé z nich používá samostatné soubory zařízení (nebo „uzly“).[9] Pro každý nalezený GPU vytvoří jeho odpovídající ovladač DRM - pokud podporuje funkci renderovacích uzlů - soubor zařízení / dev / dri / renderDX, volal vykreslovací uzel, kromě primárního uzlu / dev / dri / kartaX.[54][9] Klienti, kteří používají model přímého vykreslování, a aplikace, které chtějí využít výpočetní možnosti GPU, to mohou udělat bez nutnosti dalších oprávnění jednoduše otevřením jakéhokoli existujícího uzlu vykreslení a odesláním operací GPU pomocí omezené podmnožiny rozhraní DRM API podporovaného ty uzly - za předpokladu, že mají oprávnění systému souborů otevřete soubor zařízení. Servery pro zobrazování, kompozitory a jakýkoli jiný program, který vyžaduje API sady režimů nebo jakoukoli jinou privilegovanou operaci, musí otevřít standardní primární uzel, který uděluje přístup k plnému DRM API, a používat jej jako obvykle. Uzly vykreslení výslovně zakazují GEM blikat operace zabraňující sdílení vyrovnávací paměti pomocí nezabezpečených globálních jmen GEM; pouze PRIME (DMA-BUF) deskriptory souborů lze použít ke sdílení vyrovnávacích pamětí s jiným klientem, včetně grafického serveru.[9][54]

Hardwarová podpora

Hlavní článek: Bezplatný a otevřený ovladač grafického zařízení
DRM má být používán ovladačem grafického zařízení v uživatelském režimu, jako je např. AMD Catalyst nebo Mesa 3D. Programy v uživatelském prostoru používají Rozhraní volání systému Linux pro přístup k DRM. DRM rozšiřuje rozhraní Linux System Call o vlastní systémová volání.[55]

Subsystém Linux DRM zahrnuje zdarma a open-source ovladače pro podporu hardwaru od 3 hlavních výrobců GPU pro stolní počítače (AMD, NVIDIA a Intel), stejně jako z rostoucího počtu mobilních GPU a Systém na čipu (SoC) integrátoři. Kvalita každého řidiče se velmi liší v závislosti na míře spolupráce výrobce a dalších záležitostech.

Ovladače DRM
ŘidičOd jádraPodporovaný hardwarePodpora prodejceStav / poznámky
Radeon2.4.1AMD (dříve ATi) Radeon Řada GPU s architekturami TeraScale a GCN 1. místo & 2. gen. Včetně modelů od R100 /200 /300 /400, Radeon X1000, HD 2000 /4000 /5000 /6000 /7000 /8000, R5 / R7 / R9 200 /300 série a Kaveri APU.AnoAktivní
i9152.6.9Intel GMA Čipové sady 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G, G35, G41, G43, G45. Grafika Intel HD a Iris Grafika HD 2000/3000/2500/4000/4200/4400/4600 / P4600 / P4700 / 5000, Iris Graphics 5100, Iris Pro Graphics 5200 integrovaných GPU.AnoAktivní
novinka2.6.33[56][57]NVIDIA Tesla, Fermi, Kepler, Maxwell na základě GeForce GPU, Tegra K1, X1 SoCČástečnýAktivní
exynos3.2[58]Samsung SoC Exynos založené na ARM
vmwgfx3,2 (z inscenace)[59]Virtuální GPU pro VMware SVGA2virtuální ovladač
gma5003,3 (z inscenace)[60][61]Intel GMA 500 a další Představivost Technologies (PowerVR ) založené na grafických GPUexperimentální 2D ovladač pouze pro KMS
ast3.5[62]Řada ASpeed ​​Technologies 2000experimentální
mgag2003.5[63]Matrox Zobrazovací stroje serveru MGA-G200Pouze KMS
shmobile3.7[64]Renesas SH Mobile
tegra3.8[65]Nvidia Tegra 20, Tegra30 SoCAnoAktivní
omapdrm3.9[66]Texas Instruments OMAP 5 SoC
rcar-du3.11[67]Renesas Zobrazovací jednotky SoC R-Car
msm3.12[68][69]Qualcomm je Adreno Skupiny GPU A2xx / A3xx / A4xx (Hledík SOC)[70]
armáda3.13[71][72]Marvell Armada 510 SoC
bochs3.14[73]Virtuální VGA karty pomocí Bochs rozhraní dispi vga (např QEMU stdvga)virtuální ovladač
sti3.17[74][75]STMicroelectronics Řada SoC stiH41x
obr3,19 (z předvádění)[76][77]Freescale i.MX SoC
rockchip3.19[76][78]Rockchip GPU založené na SoCPouze KMS
amdgpu[55]4.2[79][80]AMD Radeon Řada GPU s architekturami GCN 3 & 4. gen. Včetně modelů od Radeonu Rx 200 /300 /400 /500[81] série a Carrizo a Bristol & Stoney Ridge APU.AnoAktivní
Virtio4.2[82]virtuální ovladač GPU pro QEMU správci virtuálních strojů na bázi (jako KVM nebo Xen )virtuální ovladač
vc44.4[83][84][85]Raspberry Pi je Broadcom BCM2835 a BCM2836 SoC (VideoCore IV GPU)
etnaviv4.5[86][87][88]Vivante Jádra GPU nalezená v několika SoC, jako např Marvell ARMADA a Freescale Řada i.MX6
sun4i4.7[89][90]Allwinner SoC (ARM Mali-400 GPU)
Kirin4.7[91][90]HiSilicon Kirin hi6220 SoC (ARM Mali 450-MP4 GPU)
mediatek4.7[92][90]MediaTek MT8173 SoC (představivost PowerVR GPU GX6250)
hibmc4.10[93]HiSilicon hi1710 Huawei iBMC SoC (Křemíkový obraz Jádro GPU SM750[94])Pouze KMS
lima5.2[95]ARM Mali 4xx GPU
panfrost5.2[96]GPU ARM Mali Txxx (Midgard) a Gxx (Bifrost)

K dispozici je také řada ovladačů pro starý zastaralý hardware, které jsou v historické tabulce podrobně popsány v následující tabulce. Některé z nich stále zůstávají v kódu jádra, jiné však již byly odstraněny.

Historické ovladače DRM
ŘidičOd jádraPodporovaný hardwareStav / poznámky
gama2.3.183Dlaby GLINT GMX 2000Odstraněno od 2.6.14[97]
ffb2.4Tvůrce / Creator3D (používá Sun Microsystems Ultra pracovní stanice)Odstraněno od 2.6.21[98]
tdfx2.43dfx Banshee /Voodoo3 +
mga2.4Matrox G200 /G400 / G450
r1282.4ATI Rage 128
i8102.4Intel i810
sis2.4.17SiS 300 /630/540
i8302.4.20Intel 830M / 845G / 852GM / 855GM / 865GOdstraněno od 2.6.39[99] (nahrazeno ovladačem i915)
přes2.6.13[100]PŘES Unichrome / Unichrome Pro
divoch2.6.14[101]Grafika S3 Savage 3D / MX / IX / 4 / SuperSavage / Pro / Twister

Rozvoj

Správce přímého vykreslování je vyvíjen v rámci Linuxové jádro, a jeho zdrojový kód bydlí v / drivers / gpu / drm adresář zdrojového kódu Linuxu. Správcem subsystému je Dave Airlie a další správci se starají o konkrétní ovladače.[102] Jako obvykle ve vývoji linuxového jádra zasílají své podadresáři a přispěvatelé DRM záplaty s novými funkcemi a Chyba opravy hlavního správce DRM, který je integruje do vlastního Linuxu úložiště. The DRM maintainer in turn submits all of these patches that are ready to be mainlined to Linus Torvalds whenever a new Linux version is going to be released. Torvalds, as top maintainer of the whole kernel, holds the last word on whether a patch is suitable or not for inclusion in the kernel.

For historical reasons, the source code of the libdrm library is maintained under the umbrella of the Mesa projekt.[103]

Dějiny

In 1999, while developing DRI pro XFree86, Precision Insight created the first version of DRM for the 3dfx video cards, as a Linuxové jádro náplast included within the Mesa zdrojový kód.[104] Later that year, the DRM code was mainlined in Linux kernel 2.3.18 under the /drivers/char/drm/ directory for character devices.[105] During the following years the number of supported video cards grew. When Linux 2.4.0 was released in January 2001 there was already support for Creative Labs GMX 2000, Intel i810, Matrox G200/G400 and ATI Rage 128, in addition to 3dfx Voodoo3 cards,[106] and that list expanded during the 2.4.x series, with drivers for ATI Radeon cards, some SiS video cards and Intel 830M and subsequent integrated GPUs.

The split of DRM into two components, DRM core and DRM driver, called DRM core/personality split was done during the second half of 2004,[11][107] and merged into kernel version 2.6.11.[108] This split allowed multiple DRM drivers for multiple devices to work simultaneously, opening the way to multi-GPU support.

The idea of putting all the video mode setting code in one place inside the kernel had been acknowledged for years,[109][110] but the graphics card manufacturers had argued that the only way to do the mode-setting was to use the routines provided by themselves and contained in the Video BIOS of each graphics card. Such code had to be executed using x86 skutečný režim, which prevented it from being invoked by a kernel running in chráněný režim.[44] The situation changed when Luc Verhaegen and other developers found a way to do the mode-setting natively instead of BIOS-based,[111][44] showing that it was possible to do it using normal kernel code and laying the groundwork for what would become Kernel Mode Setting. In May 2007 Jesse Barnes (Intel ) published the first proposal for a drm-modesetting API and a working native implementation of mode-setting for Intel GPUs within the i915 DRM driver.[42] In December 2007 Jerome Glisse started to add the native mode-setting code for ATI cards to the radeon DRM driver.[112][113] Work on both the API and drivers continued during 2008, but got delayed by the necessity of a memory manager also in kernel space to handle the framebuffers.[114]

In October 2008 the Linux kernel 2.6.27 brought a major zdrojový kód reorganization, prior to some significant upcoming changes. The DRM source code tree was moved to its own source directory /drivers/gpu/drm/ and the different drivers were moved into their own subdirectories. Headers were also moved into a new /include/drm directory.[115]

The increasing complexity of video memory management led to several approaches to solving this issue. The first attempt was the Translation Table Maps (TTM) memory manager, developed by Thomas Hellstrom (Tungsten Graphics ) in collaboration with Eric Anholt (Intel) and Dave Airlie (červená čepice ).[5] TTM was proposed for inclusion into mainline kernel 2.6.25 in November 2007,[5] and again in May 2008, but was ditched in favor of a new approach called Graphics Execution Manager (GEM).[24] GEM was first developed by Keith Packard and Eric Anholt from Intel as simpler solution for memory management for their i915 driver.[6] GEM was well received and merged into the Linux kernel version 2.6.28 released in December 2008.[116] Meanwhile, TTM had to wait until September 2009 to be finally merged into Linux 2.6.31 as a requirement of the new Radeon KMS DRM driver.[117]

With memory management in place to handle buffer objects, DRM developers could finally add to the kernel the already finished API and code to do nastavení režimu. This expanded API is what is called Kernel Mode-setting (KMS) and the drivers which implement it are often referred to as KMS drivers. In March 2009, KMS was merged into the Linux kernel version 2.6.29,[30][118] along with KMS support for the i915 driver.[119] The KMS API have been exposed to user space programs since libdrm 2.4.3.[120] The userspace X.Org DDX driver for Intel graphics cards was also the first to use the new GEM and KMS APIs.[121] KMS support for the radeon DRM driver was added to Linux 2.6.31 release of September 2009.[122][123][124] The new radeon KMS driver used the TTM memory manager but exposed GEM-compatible interfaces and ioctls instead of TTM ones.[23]

Since 2006 the nouveau project had been developing a svobodný software DRM driver for NVIDIA GPUs outside of the official Linux kernel. In 2010 the nouveau source code was merged into Linux 2.6.33 as an experimental driver.[56][57] At the time of merging, the driver had been already converted to KMS, and behind the GEM API it used TTM as its memory manager.[125]

The new KMS API—including the GEM API—was a big milestone in the development of DRM, but it didn't stop the API for being enhanced in the following years. KMS gained support for page flips in conjunction with asyncronous VBLANK notifications in Linux 2.6.33[126][127]—only for the i915 driver, radeon and nouveau added it later during Linux 2.6.38 release.[128] The new page flip interface was added to libdrm 2.4.17.[129] In early 2011, during the Linux 2.6.39 release cycle, the so-called hloupé nárazníky—a hardware-independent non-accelerated way to handle simple buffers suitable for use as framebuffers—were added to the KMS API.[130][131] The goal was to reduce the complexity of applications such as Plymouth that don't need to use special accelerated operations provided by driver-specific ioctls.[132] The feature was exposed by libdrm from version 2.4.25 onwards.[133] Later that year it also gained a new main type of objects, called letadla. Planes were developed to represent hardware overlays supported by the scanout engine.[134][135] Plane support was merged into Linux 3.3.[136] and libdrm 2.4.30. Another concept added to the API—during Linux 3.5[137] and libdrm 2.4.36[138] releases—were generic object properties, a method to add generic values to any KMS object. Properties are specially useful to set special behaviour or features to objects such as CRTCs and planes.

An early proof of concept to provide GPU offloading between DRM drivers was developed by Dave Airlie in 2010.[7][139] Since Airlie was trying to mimic the NVIDIA Optimus technology, he decided to name it "PRIME".[7] Airlie resumed his work on PRIME in late 2011, but based on the new DMA-BUF buffer sharing mechanism introduced by Linux kernel 3.3.[140] The basic DMA-BUF PRIME infrastructure was finished in March 2012[141] and merged into the Linux 3.4 release,[142][143][144] as well as into libdrm 2.4.34.[145] Later during the Linux 3.5 release, several DRM drivers implemented PRIME support, including i915 for Intel cards, radeon for AMD cards and nouveau for NVIDIA cards.[146][147]

In recent years, the DRM API has incrementally expanded with new and improved features. In 2013, as part of GSoC, David Herrmann developed the multiple render nodes Vlastnosti.[53] His code was added to the Linux kernel version 3.12 as an experimental feature[148][149] supported by i915,[150] radeon[151] and nouveau[152] drivers, and enabled by default since Linux 3.17.[75] In 2014 Matt Roper (Intel) developed the universal planes (nebo unified planes) concept by which framebuffers (primary planes), overlays (secondary planes) and cursors (cursor planes) are all treated as a single type of object with an unified API.[153] Universal planes support provides a more consistent DRM API with fewer, more generic ioctls.[33] In order to maintain the API zpětně kompatibilní, the feature is exposed by DRM core as an additional capability that a DRM driver can provide. Universal plane support debuted in Linux 3.15[154] and libdrm 2.4.55.[155] Several drivers, such as the Intel i915,[156] have already implemented it.

The most recent DRM API enhancement is the atomic mode-setting API, which brings atomicity to the mode-setting and page flipping operations on a DRM device. The idea of an atomic API for mode-setting was first proposed in early 2012.[157] Ville Syrjälä (Intel) took over the task of designing and implementing such atomic API.[158] Based on his work, Rob Clark (Texas Instruments ) took a similar approach aiming to implement atomic page flips.[159] Later in 2013 both proposed features were reunited in a single one using a single ioctl for both tasks.[160] Since it was a requirement, the feature had to wait for the support of universal planes to be merged in mid-2014.[156] During the second half of 2014 the atomic code was greatly enhanced by Daniel Vetter (Intel) and other DRM developers[161]:18 in order to facilitate the transition for the existing KMS drivers to the new atomic framework.[162] All of this work was finally merged into Linux 3.19[163] and Linux 4.0[164][165][166] releases, and enabled by default since Linux 4.2.[167] libdrm exposed the new atomic API since version 2.4.62.[168] Multiple drivers have already been converted to the new atomic API.[169] By 2018 ten new DRM drivers based on this new atomic model had been added to the Linux kernel.[170]

Přijetí

The Direct Rendering Manager kernel subsystem was initially developed to be used with the new Direct Rendering Infrastructure z XFree86 4.0 display server, later inherited by its successor, the X.Org Server. Therefore, the main users of DRM were DRI clients that link to the hardware-accelerated OpenGL implementation that lives in the Mesa 3D library, as well as the X Server itself. Nowadays DRM is also used by several Skládače Wayland, počítaje v to Weston reference compositor. kmscon is a virtual console implementation that runs in user space using DRM KMS facilities.[171]

In 2015, version 358.09 (beta) of the proprietary Nvidia GeForce driver received support for the DRM mode-setting interface implemented as a new kernel blob called nvidia-modeset.ko. This new driver component works in conjunction with the nvidia.ko kernel module to program the display engine (i.e. display controller) of the GPU.[172]

Viz také

Reference

  1. ^ "Linux kernel/drivers/gpu/drm/README.drm". kernel.org. Archivovány od originál dne 26.02.2014. Citováno 2014-02-26.
  2. ^ A b Uytterhoeven, Geert. "The Frame Buffer Device". Kernel.org. Citováno 28. ledna 2015.
  3. ^ A b C White, Thomas. "How DRI and DRM Work". Citováno 22. července 2014.
  4. ^ Faith, Rickard E. (11 May 1999). "The Direct Rendering Manager: Kernel Support for the Direct Rendering Infrastructure". Citováno 12. května 2016.
  5. ^ A b C d E F G h Corbet, Jonathan (6 November 2007). "Memory management for graphics processors". LWN.net. Citováno 23. července 2014.
  6. ^ A b C d E F G Packard, Keith; Anholt, Eric (13 May 2008). "GEM - the Graphics Execution Manager". dri-devel mailing list. Citováno 23. července 2014.
  7. ^ A b C Airlie, Dave (12 March 2010). "GPU offloading - PRIME - proof of concept". Archivovány od originál dne 10. února 2015. Citováno 10. února 2015.
  8. ^ A b C d E Kitching, Simon. "DRM and KMS kernel modules". Citováno 13. května 2016.
  9. ^ A b C d E Herrmann, David (1 September 2013). "Splitting DRM and KMS device nodes". Citováno 23. července 2014.
  10. ^ "README.rst - mesa/drm - Direct Rendering Manager headers and kernel modules". 2020-03-21. Archivovány od originál on 2020-03-21.
  11. ^ A b Airlie, Dave (4 September 2004). "New proposed DRM interface design". dri-devel (Poštovní seznam).
  12. ^ A b C d E F G Peres, Martin; Ravier, Timothée (2 February 2013). "DRI-next/DRM2: A walkthrough the Linux Graphics stack and its security" (PDF). Citováno 13. května 2016.
  13. ^ Høgsberg, Kristian (4 September 2008). "The DRI2 Extension - Version 2.0". X.Org. Citováno 23. května 2016.
  14. ^ A b C d E F Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - Memory management". Citováno 31. srpna 2016.
  15. ^ Vetter, Daniel. "i915/GEM Crashcourse by Daniel Vetter". Intel Open Source Technology Center. Citováno 31. ledna 2015. GEM essentially deals with graphics buffer objects (which can contain textures, renderbuffers, shaders, or all kinds of other state objects and data used by the gpu)
  16. ^ A b C Vetter, Daniel (4 May 2011). "GEM Overview". Citováno 13. února 2015.
  17. ^ Packard, Keith (28 September 2012). "Thoughts about DRI.Next". Citováno 26. května 2016. GEM flink has lots of issues. The flink names are global, allowing anyone with access to the device to access the flink data contents.
  18. ^ A b Herrmann, David (2 July 2013). "DRM Security". The 2013 X.Org Developer's Conference (XDC2013) Proceedings. Citováno 13. února 2015. gem-flink doesn't provide any private namespaces to applications and servers. Instead, only one global namespace is provided per DRM node. Malicious authenticated applications can attack other clients via brute-force "name-guessing" of gem buffers
  19. ^ Kerrisk, Michael (25. září 2012). „XDC2012: Zabezpečení grafického zásobníku“. LWN.net. Citováno 25. listopadu 2015.
  20. ^ A b Packard, Keith (4 July 2008). "gem update". Citováno 25. dubna 2016.
  21. ^ "drm-memory man page". Ubuntu manuals. Citováno 29. ledna 2015. Many modern high-end GPUs come with their own memory managers. They even include several different caches that need to be synchronized during access. [...]. Therefore, memory management on GPUs is highly driver- and hardware-dependent.
  22. ^ "Intel Graphics Media Accelerator Developer's Guide". Intel Corporation. Citováno 24. listopadu 2015.
  23. ^ A b C Larabel, Michael (26 August 2008). "A GEM-ified TTM Manager For Radeon". Phoronix. Citováno 24. dubna 2016.
  24. ^ A b C Corbet, Jonathan (28 May 2008). "GEM v. TTM". LWN.net. Citováno 10. února 2015.
  25. ^ Corbet, Jonathan (11 January 2012). "DMA buffer sharing in 3.3". LWN.net. Citováno 14. května 2016.
  26. ^ Clark, Rob; Semwal, Sumit. "DMA Buffer Sharing Framework: An Introduction" (PDF). Citováno 14. května 2016.
  27. ^ Peres, Martin (26 September 2014). "The Linux graphics stack, Optimus and the Nouveau driver" (PDF). Citováno 14. května 2016.
  28. ^ Pinchart, Laurent (20 February 2013). "Anatomy of an Embedded KMS Driver" (PDF). Citováno 27. června 2016.
  29. ^ Edge, Jake (9 October 2013). "DRI3 and Present". LWN.net. Citováno 28. května 2016.
  30. ^ A b C d "Linux 2.6.29 - Kernel Modesetting". Linux Kernel Newbies. Citováno 19. listopadu 2015.
  31. ^ "VGA Hardware". OSDev.org. Citováno 23. listopadu 2015.
  32. ^ Rathmann, B. (15 February 2008). "The state of Nouveau, part I". LWN.net. Citováno 23. listopadu 2015. Graphics cards are programmed in numerous ways, but most initialization and mode setting is done via memory-mapped IO. This is just a set of registers accessible to the CPU via its standard memory address space. The registers in this address space are split up into ranges dealing with various features of the graphics card such as mode setup, output control, or clock configuration.
  33. ^ A b C d E Paalanen, Pekka (5 June 2014). "From pre-history to beyond the global thermonuclear war". Citováno 29. července 2014.
  34. ^ "drm-kms man page". Ubuntu manuals. Citováno 19. listopadu 2015.
  35. ^ Corbet, Jonathan (13 January 2010). "The end of user-space mode setting?". LWN.net. Citováno 20. listopadu 2015.
  36. ^ A b "Mode Setting Design Discussion". X.Org Wiki. Citováno 19. listopadu 2015.
  37. ^ A b Corbet, Jonathan (22 January 2007). "LCA: Updates on the X Window System". LWN.net. Citováno 23. listopadu 2015.
  38. ^ "XF86VIDMODE manual page". X.Org. Citováno 23. dubna 2016.
  39. ^ "X11R6.1 Release Notes". X.Org. 14. března 1996. Citováno 23. dubna 2016.
  40. ^ Corbet, Jonathan (20 July 2004). "Kernel Summit: Video Drivers". LWN.net. Citováno 23. listopadu 2015.
  41. ^ A b "Fedora - Features/KernelModeSetting". Fedora Project. Citováno 20. listopadu 2015. Historically, the X server was responsible for saving output state when it started up, and then restoring it when it switched back to text mode. Fast user switching was accomplished with a VT switch, so switching away from the first user's X server would blink once to go to text mode, then immediately blink again to go to the second user's session.
  42. ^ A b C d E Barnes, Jesse (17 May 2007). "[RFC] enhancing the kernel's graphics subsystem". linux-kernel (Poštovní seznam).
  43. ^ A b C "DrmModesetting - Enhancing kernel graphics". DRI Wiki. Citováno 23. listopadu 2015.
  44. ^ A b C d E Packard, Keith (16 September 2007). "kernel-mode-drivers". Citováno 30. dubna 2016.
  45. ^ A b Packard, Keith (24 April 2000). "Sharpening the Intel Driver Focus". Citováno 23. května 2016. A more subtle limitation is that the driver couldn't handle interrupts, so there wasn't any hot-plug monitor support.
  46. ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - Driver Initialization". Citováno 31. srpna 2016.
  47. ^ A b C d E F G Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - KMS Initialization and Cleanup". Citováno 31. srpna 2016.
  48. ^ A b "Video Cards". X.Org Wiki. Citováno 11. dubna 2016.
  49. ^ A b Deucher, Alex (15 April 2010). "Notes about radeon display hardware". Archivovány od originál dne 5. dubna 2016. Citováno 8. dubna 2016.
  50. ^ A b C d E Vetter, Daniel (5 August 2015). "Atomic mode setting design overview, part 1". LWN.net. Citováno 7. května 2016.
  51. ^ A b Reding, Thierry (1 February 2015). "Atomic Mode-Setting" (PDF). FOSDEM Archives. Citováno 7. května 2016.
  52. ^ Vetter, Daniel (12 August 2015). "Atomic mode setting design overview, part 2". LWN.net. Citováno 7. května 2016.
  53. ^ A b C Herrmann, David (29 May 2013). "DRM Render- and Modeset-Nodes". Citováno 21. července 2014.
  54. ^ A b C d Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - Render nodes". Citováno 31. srpna 2016.
  55. ^ A b Deucher, Alex (20 April 2015). "Initial amdgpu driver release". dri-devel (Poštovní seznam).
  56. ^ A b "Linux 2.6.33 - Nouveau, a driver for Nvidia graphic cards". Linux Kernel Newbies. Citováno 26. dubna 2016.
  57. ^ A b "drm/nouveau: Add DRM driver for NVIDIA GPUs". Kernel.org. Citováno 27. ledna 2015.
  58. ^ "DRM: add DRM Driver for Samsung SoC EXYNOS4210". Kernel.org. Citováno 3. března 2016.
  59. ^ "vmwgfx: Take the driver out of staging". Kernel.org. Citováno 3. března 2016.
  60. ^ "Linux 3.3 - DriverArch - Graphics". Linux Kernel Newbies. Citováno 3. března 2016.
  61. ^ Larabel, Michael (10 January 2012). "The Linux 3.3 DRM Pull Is Heavy On Enhancements". Phoronix. Citováno 3. března 2016.
  62. ^ "drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)". Kernel.org. Citováno 3. března 2016.
  63. ^ Airlie, Dave (17 May 2012). "mgag200: initial g200se driver (v2)". Citováno 24. ledna 2018.
  64. ^ "drm: Renesas SH Mobile DRM driver". Kernel.org. Citováno 3. března 2016.
  65. ^ "drm: Add NVIDIA Tegra20 support". Kernel.org. Citováno 3. března 2016.
  66. ^ "drm/omap: move out of staging". Kernel.org. Citováno 3. března 2016.
  67. ^ "drm: Renesas R-Car Display Unit DRM driver". Kernel.org. Citováno 3. března 2016.
  68. ^ "drm/msm: basic KMS driver for snapdragon". Kernel.org. Citováno 3. března 2016.
  69. ^ Larabel, Michael (28 August 2013). "Snapdragon DRM/KMS Driver Merged For Linux 3.12". Phoronix. Citováno 26. ledna 2015.
  70. ^ Edge, Jake (8 April 2015). "An update on the freedreno graphics driver". LWN.net. Citováno 23. dubna 2015.
  71. ^ King, Russell (18 October 2013). "[GIT PULL] Armada DRM support". dri-devel (Poštovní seznam).
  72. ^ "DRM: Armada: Add Armada DRM driver". Kernel.org. Citováno 3. března 2016.
  73. ^ "drm/bochs: new driver". Kernel.org. Citováno 3. března 2016.
  74. ^ Larabel, Michael (8 August 2014). "Linux 3.17 DRM Pull Brings New Graphics Driver". Phoronix. Citováno 3. března 2016.
  75. ^ A b Corbet, Jonathan (13 August 2014). "3.17 merge window, part 2". LWN.net. Citováno 7. října 2014.
  76. ^ A b Corbet, Jonathan (17 December 2014). "3.19 Merge window part 2". LWN.net. Citováno 9. února 2015.
  77. ^ "drm: imx: Move imx-drm driver out of staging". Kernel.org. Citováno 9. února 2015.
  78. ^ "drm: rockchip: Add basic drm driver". Kernel.org. Citováno 3. března 2016.
  79. ^ Larabel, Michael (25 June 2015). "Linux 4.2 DRM Updates: Lots Of AMD Attention, No Nouveau Driver Changes". Phoronix. Citováno 31. srpna 2015.
  80. ^ Corbet, Jonathan (1 July 2015). "4.2 Merge window part 2". LWN.net. Citováno 31. srpna 2015.
  81. ^ Deucher, Alex (3 August 2015). "[PATCH 00/11] Add Fiji Support". dri-devel (Poštovní seznam).
  82. ^ "Add virtio gpu driver". Kernel.org. Citováno 3. března 2016.
  83. ^ Corbet, Jonathan (11 November 2015). "4.4 Merge window, part 1". LWN.net. Citováno 11. ledna 2016.
  84. ^ Larabel, Michael (15 November 2015). "A Look At The New Features Of The Linux 4.4 Kernel". Phoronix. Citováno 11. ledna 2016.
  85. ^ "drm/vc4: Add KMS support for Raspberry Pi". Kernel.org.
  86. ^ "Linux 4.5-DriversArch - Graphics". Linux Kernel Newbies. Citováno 14. března 2016.
  87. ^ Larabel, Michael (24 January 2016). "The Many New Features & Improvements Of The Linux 4.5 Kernel". Phoronix. Citováno 14. března 2016.
  88. ^ Corbet, Jonathan (20 January 2016). "4.5 merge window part 2". LWN.Net. Citováno 14. března 2016.
  89. ^ "Merge tag 'sun4i-drm-for-4.7'". Kernel.org.
  90. ^ A b C Airlie, Dave (23 May 2016). "[git pull] drm for v4.7". dri-devel (Poštovní seznam).
  91. ^ "Merge tag 'drm-hisilicon-next-2016-04-29'". Kernel.org.
  92. ^ "Merge tag 'mediatek-drm-2016-05-09'". Kernel.org.
  93. ^ Larabel, Michael (22 November 2016). "Hisilicon Hibmc DRM Driver Being Added For Linux 4.10". Phoronix. Citováno 24. ledna 2018.
  94. ^ "Huawei FusionServer RH5885 V3 Technical White Paper". 18 November 2016. uses an onboard display chip that is integrated into the management chip Hi1710 and uses the IP core of the SM750
  95. ^ „kernel / git / torvalds / linux.git - zdrojový strom jádra Linuxu“. git.kernel.org. Citováno 2019-11-28.
  96. ^ „kernel / git / torvalds / linux.git - zdrojový strom jádra Linuxu“. git.kernel.org. Citováno 2019-11-28.
  97. ^ "drm: remove the gamma driver". Kernel.org. Citováno 27. ledna 2015.
  98. ^ "[DRM]: Delete sparc64 FFB driver code that never gets built". Kernel.org. Citováno 27. ledna 2015.
  99. ^ "drm: remove i830 driver". Kernel.org. Citováno 27. ledna 2015.
  100. ^ "drm: Add via unichrome support". Kernel.org. Citováno 27. ledna 2015.
  101. ^ "drm: add savage driver". Kernel.org. Citováno 27. ledna 2015.
  102. ^ "List of maintainers of the linux kernel". Kernel.org. Citováno 14. července 2014.
  103. ^ "libdrm git repository". Citováno 23. července 2014.
  104. ^ "First DRI release of 3dfx driver". Mesa 3D. Citováno 15. července 2014.
  105. ^ "Import 2.3.18pre1". The History of Linux in GIT Repository Format 1992-2010 (2010). Citováno 15. července 2014.
  106. ^ Torvalds, Linus. "Linux 2.4.0 source code". Kernel.org. Citováno 29. července 2014.
  107. ^ Airlie, Dave (30 December 2004). "[bk pull] drm core/personality split". linux-kernel (Poštovní seznam).
  108. ^ Torvalds, Linus (11 January 2005). "Linux 2.6.11-rc1". linux-kernel (Poštovní seznam).
  109. ^ Gettys, James; Packard, Keith (15 June 2004). "The (Re)Architecture of the X Window System". Citováno 30. dubna 2016.
  110. ^ Smirl, Jon (30 August 2005). "The State of Linux Graphics". Citováno 30. dubna 2016. I believe the best solution to this problem is for the kernel to provide a single, comprehensive device driver for each piece of video hardware. This means that conflicting drivers like fbdev and DRM must be merged into a cooperating system. It also means that poking hardware from user space while a kernel based device driver is loaded should be prevented.
  111. ^ Verhaegen, Luc (2 March 2006). "X and Modesetting: Atrophy illustrated" (PDF). Citováno 30. dubna 2016.
  112. ^ Glisse, Jerome (4 December 2007). "Radeon kernel modesetting". Citováno 30. dubna 2016.
  113. ^ Larabel, Michael (1 October 2008). "The State of Kernel Mode-Setting". Phoronix. Citováno 30. dubna 2016.
  114. ^ Packard, Keith (21 July 2008). "X output status july 2008". Citováno 1. května 2016.
  115. ^ "drm: reorganise drm tree to be more future proof". Kernel.org.
  116. ^ "Linux 2.6.28 - The GEM Memory Manager for GPU memory". Linux Kernel Newbies. Citováno 23. července 2014.
  117. ^ "drm: Add the TTM GPU memory manager subsystem". Kernel.org.
  118. ^ "DRM: add mode setting support". Kernel.org.
  119. ^ "DRM: i915: add mode setting support". Kernel.org.
  120. ^ Anholt, Eric (22 December 2008). "[ANNOUNCE] libdrm-2.4.3". dri-devel (Poštovní seznam).
  121. ^ Barnes, Jesse (20 October 2008). "[ANNOUNCE] xf86-video-intel 2.5.0". xorg-announce (Poštovní seznam).
  122. ^ "Linux 2.6.31 - ATI Radeon Kernel Mode Setting support". Linux Kernel Newbies. Archivovány od originál dne 5. listopadu 2015. Citováno 28. dubna 2016.
  123. ^ Torvalds, Linus (9 September 2009). "Linux 2.6.31". linux-kernel (Poštovní seznam).
  124. ^ "drm/radeon: introduce kernel modesetting for radeon hardware". Kernel.org.
  125. ^ "The irregular Nouveau Development Companion #40". Nouveau project. Citováno 3. května 2016.
  126. ^ "Linux 2.6.33 - Graphic improvements". Linux Kernel Newbies. Citováno 28. dubna 2016.
  127. ^ "drm/kms: add page flipping ioctl". Kernel.org.
  128. ^ "Linux 2.6.38 - Graphics". Linux Kernel Newbies. Citováno 28. dubna 2016.
  129. ^ Airlie, Dave (21 December 2009). "[ANNOUNCE] libdrm 2.4.17". dri-devel (Poštovní seznam).
  130. ^ "drm: dumb scanout create/mmap for intel/radeon (v3)". Kernel.org.
  131. ^ "Linux 2 6 39-DriversArch". Linux Kernel Newbies. Citováno 19. dubna 2016.
  132. ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Linux GPU Driver Developer's Guide - Dumb Buffer Objects". Citováno 31. srpna 2016.
  133. ^ Wilson, Chris (11 April 2011). "[ANNOUNCE] libdrm 2.4.25". dri-devel (Poštovní seznam).
  134. ^ Barnes, Jesse (25 April 2011). "[RFC] drm: add overlays as first class KMS objects". dri-devel (Poštovní seznam).
  135. ^ Barnes, Jesse (13 May 2011). "[RFC] drm: add overlays as first class KMS objects". dri-devel (Poštovní seznam).
  136. ^ "drm: add plane support v3". Kernel.org.
  137. ^ "drm: add generic ioctls to get/set properties on any object". Kernel.org.
  138. ^ Widawsky, Ben (27 June 2012). "[ANNOUNCE] libdrm 2.4.36". xorg-announce (Poštovní seznam).
  139. ^ Larabel, Michael. "Proof Of Concept: Open-Source Multi-GPU Rendering!". Phoronix. Citováno 14. dubna 2016.
  140. ^ Larabel, Michael (23 February 2012). "DRM Base PRIME Support Part Of VGEM Work". Phoronix. Citováno 14. dubna 2016.
  141. ^ Airlie, Dave (27 March 2012). "[PATCH] drm: base prime/dma-buf support (v5)". dri-devel (Poštovní seznam).
  142. ^ Larabel, Michael (30 March 2012). "Last Minute For Linux 3.4: DMA-BUF PRIME Support". Phoronix. Citováno 15. dubna 2016.
  143. ^ "drm: base prime/dma-buf support (v5)". Kernel.org.
  144. ^ "Linux 3.4 DriverArch". Linux Kernel Newbies. Citováno 15. dubna 2016.
  145. ^ Anholt, Eric (10 May 2012). "[ANNOUNCE] libdrm 2.4.34". dri-devel (Poštovní seznam).
  146. ^ Larabel, Michael (12. května 2012). "DMA-BUF PRIME Coming Together For Linux 3.5". Phoronix. Citováno 15. dubna 2016.
  147. ^ "Linux 3.5 DriverArch". Linux Kernel Newbies. Citováno 15. dubna 2016.
  148. ^ Corbet, Jonathan (11 September 2013). "3.12 merge window, part 2". LWN.net. Citováno 21. července 2014.
  149. ^ "drm: implement experimental render nodes". Kernel.org.
  150. ^ "drm/i915: Support render nodes". Kernel.org.
  151. ^ "drm/radeon: Support render nodes". Kernel.org.
  152. ^ "drm/nouveau: Support render nodes". Kernel.org.
  153. ^ Roper, Matt (7 March 2014). "[RFCv2 00/10] Universal plane support". dri-devel (Poštovní seznam).
  154. ^ Larabel, Michael (2 April 2014). "Universal Plane Support Set For Linux 3.15". Phoronix. Citováno 14. dubna 2016.
  155. ^ Lankhorst, Maarten (25 July 2014). "[ANNOUNCE] libdrm 2.4.55". dri-devel (Poštovní seznam).
  156. ^ A b Vetter, Daniel (7 August 2014). "Neat stuff for 3.17". Citováno 14. dubna 2016.
  157. ^ Barnes, Jesse (15 February 2012). "[RFC] drm: atomic mode set API". dri-devel (Poštovní seznam).
  158. ^ Syrjälä, Ville (24 May 2012). "[RFC][PATCH 0/6] WIP: drm: Atomic mode setting idea". dri-devel (Poštovní seznam).
  159. ^ Clark, Rob (9 September 2012). "[RFC 0/9] nuclear pageflip". dri-devel (Poštovní seznam).
  160. ^ Clark, Rob (6 October 2013). "[RFCv1 00/12] Atomic/nuclear modeset/pageflip". dri-devel (Poštovní seznam).
  161. ^ Vetter, Daniel (3 February 2016). "Embrace the Atomic Display Age" (PDF). Citováno 4. května 2016.
  162. ^ Vetter, Daniel (2 November 2014). "Atomic Modeset Support for KMS Drivers". Citováno 4. května 2016.
  163. ^ Airlie, Dave (14 December 2014). "[git pull] drm for 3.19-rc1". dri-devel (Poštovní seznam).
  164. ^ Vetter, Daniel (28 January 2015). "Update for Atomic Display Updates". Citováno 4. května 2016.
  165. ^ Airlie, Dave (15 February 2015). "[git pull] drm pull for 3.20-rc1". dri-devel (Poštovní seznam).
  166. ^ "Linux 4.0 - DriverArch - Graphics". Linux Kernel Newbies. Citováno 3. května 2016.
  167. ^ "Linux 4.2 - Atomic modesetting API enabled by default". Linux Kernel Newbies. Citováno 3. května 2016.
  168. ^ Velikov, Emil (29 June 2015). "[ANNOUNCE] libdrm 2.4.62". dri-devel (Poštovní seznam).
  169. ^ Vetter, Daniel (6 June 2016). "Awesome Atomic Advances". Citováno 7. června 2016. right now there's 17 drivers supporting atomic modesetting merged into the DRM subsystem
  170. ^ Stone, Daniel (20 March 2018). "A new era for Linux's low-level graphics - Part 1". Citováno 5. května 2018.
  171. ^ Herrmann, David (10 December 2012). "KMSCON Introduction". Citováno 22. listopadu 2015.
  172. ^ "Linux, Solaris, and FreeBSD driver 358.09 (beta)". 2015-12-10.

externí odkazy