Infrastruktura přímého vykreslování - Direct Rendering Infrastructure
Původní autoři | Precision Insight, wolframová grafika |
---|---|
Vývojáři | freedesktop.org |
První vydání | Srpna 1998[1] |
Stabilní uvolnění | 2.4.x / únor 2009 |
Napsáno | C |
Plošina | POSIX |
Typ | Rámec / API |
Licence | MIT a další licence[2] |
webová stránka | dri |
Původní autoři | Kristian Høgsberg et al. |
---|---|
Vývojáři | freedesktop.org |
První vydání | 4. září 2008[3] |
Stabilní uvolnění | 2.8 / 11. července 2012[4] |
Napsáno | C |
Plošina | POSIX |
Typ | Rámec / API |
Licence | MIT a další licence[2] |
webová stránka | dri |
Původní autoři | Keith Packard et al. |
---|---|
Vývojáři | freedesktop.org |
První vydání | 1. listopadu 2013[5] |
Stabilní uvolnění | 1.0 / 1. listopadu 2013[5] |
Napsáno | C |
Plošina | POSIX |
Typ | Rámec / API |
Licence | MIT a další licence[2] |
webová stránka | dri |



The Infrastruktura přímého vykreslování (DRI) je rámec umožňující přímý přístup k grafický hardware pod Systém X Window bezpečným a efektivním způsobem.[6] Hlavním využitím DRI je poskytovat hardwarovou akceleraci pro Mesa implementace OpenGL. DRI byl také upraven tak, aby poskytoval akceleraci OpenGL na a konzole framebuffer bez zobrazovací server běh.[7]
Implementace DRI je roztroušena po X Server a přidružené klientské knihovny, Mesa 3D a Správce přímého vykreslování subsystém jádra.[6] Všechno zdrojový kód je svobodný software.
Přehled
V klasice Systém X Window architektura X Server je jediný proces s exkluzivním přístupem k grafický hardware, a tedy ten, který dělá skutečné vykreslování na framebuffer. Vše, co klienti X dělají, je komunikovat se serverem X a odesílat příkazy vykreslování. Tyto příkazy jsou nezávislé na hardwaru, což znamená, že Protokol X11 poskytuje API který abstrahuje grafické zařízení, takže X klienti nepotřebují vědět nebo si dělat starosti o specifika podkladového hardwaru. Veškerý hardware specifický kód žije uvnitř Závislé na zařízení X část serveru X, která spravuje každý typ grafické karty nebo grafického adaptéru a která se také často nazývá video nebo grafický ovladač.
Povstání 3D vykreslování ukázal limity této architektury. 3D grafické aplikace mají tendenci produkovat velké množství příkazů a dat, které všechny musí být odeslány na X Server pro vykreslení. Jako množství meziprocesová komunikace (IPC) mezi klientem X a serverem X Server, výkon 3D vykreslování utrpěl natolik, že vývojáři ovladačů X dospěli k závěru, že k využití možností 3D hardwaru nejnovějších grafických karet je vyžadována nová architektura bez IPC. Klienti X by měli mít spíše přímý přístup ke grafickému hardwaru, než aby se spoléhali na to, že tak učiní proces třetí strany, čímž se ušetří veškerá režie IPC. Tento přístup se nazývá „přímé vykreslování“ na rozdíl od „nepřímého vykreslování“ poskytovaného klasickou architekturou X. The Infrastruktura přímého vykreslování byl původně vyvinut tak, aby umožňoval jakémukoli klientovi X provádět 3D vykreslování pomocí tohoto přístupu „přímého vykreslování“.
Nic nebrání tomu, aby DRI bylo použito k implementaci zrychleného 2D přímého vykreslování v X klientovi.[3] Prostě to nikdo nepotřeboval, protože výkon 2D nepřímého vykreslování byl dost dobrý.
Softwarová architektura
Základní architektura Direct Rendering Infrastructure zahrnuje tři hlavní komponenty:[8]
- klient DRI - klient X provádějící „přímé vykreslování“ - potřebuje hardwarově specifický „ovladač“ schopný spravovat aktuální grafickou kartu nebo grafický adaptér, aby se na něm mohl vykreslit. Tyto Ovladače DRI jsou obvykle poskytovány jako sdílené knihovny klientem dynamicky propojeno. Vzhledem k tomu, že DRI bylo koncipováno tak, aby využívalo výhody 3D grafického hardwaru, jsou knihovny běžně klientům prezentovány jako hardwarově akcelerované implementace 3D API, jako je OpenGL, poskytované samotným prodejcem 3D hardwaru nebo třetí stranou, jako je Mesa 3D svobodný software projekt.
- X Server poskytuje Rozšíření protokolu X11 —Přípona DRI—, kterou používají klienti DRI ke koordinaci s oběma okenní systém a ovladač DDX.[9] Jako součást ovladače DDX je zcela běžné, že se proces X Serveru také dynamicky připojuje ke stejnému ovladači DRI jako klienti DRI, ale aby klientům X poskytoval hardwarově akcelerované 3D vykreslování pomocí GLX rozšíření pro nepřímé vykreslování (například vzdálení X klienti, kteří nemohou používat přímé vykreslování). U 2D vykreslování musí ovladač DDX brát v úvahu také klienty DRI používající stejné grafické zařízení.
- přístup k grafické kartě nebo grafickému adaptéru je regulován komponentou jádra zvanou Správce přímého vykreslování (DRM).[10] Ovladač DDX serveru X Server i ovladač DRI každého klienta X musí pro přístup ke grafickému hardwaru používat DRM. DRM poskytuje synchronizace ke sdíleným zdrojům grafického hardwaru - zdroje, jako je příkazová fronta, registry karet, videopaměť, motory DMA, ... - zajišťující, aby souběžný přístup všech těchto více konkurenčních procesů uživatelského prostoru nezasahoval do navzájem. DRM slouží také jako základní vynucovač zabezpečení, který neumožňuje žádnému klientovi X přístup k hardwaru nad rámec toho, co potřebuje k provedení 3D vykreslování.
DRI1
V původní architektuře DRI kvůli velikosti paměti grafické karty v té době existovala jediná instance obrazovky přední nárazník a zadní vyrovnávací paměť (také doplňkové hloubkový nárazník a vyrovnávací paměť šablony ), sdílené všemi klienty DRI a X serverem.[11][12] Všechny byly vykresleny přímo do zadní paměti, to bylo vyměnil s předním nárazníkem v interval vertikálního zaslepení čas.[11] Aby bylo možné vykreslit do zadní vyrovnávací paměti, měl by proces DRI zajistit, že vykreslení bylo oříznut do oblasti vyhrazené pro jeho okno.[11][12]
The synchronizace se serverem X bylo provedeno prostřednictvím signály a a sdílená paměť nárazník zvaný SAREA.[12] Přístup k zařízení DRM byl exkluzivní, takže každý klient DRI musel zámek to na začátku a vykreslování úkon. Ostatní uživatelé zařízení - včetně X Serveru - byli mezitím zablokováni a museli počkat, až se zámek uvolní na konci aktuální operace vykreslování, i když by to nebyl žádný konflikt mezi oběma operacemi.[12] Další nevýhodou bylo, že operace nezachovaly přidělení paměti poté, co aktuální proces DRI uvolnil svůj zámek na zařízení, takže veškerá data nahraná do grafické paměti, jako například textury byly ztraceny pro nadcházející operace, což mělo značný dopad na grafický výkon.
V dnešní době je DRI1 považován za zcela zastaralý a nesmí se používat.
DRI2
Vzhledem k rostoucí popularitě skládání správců oken jako Compiz, Infrastruktura přímého vykreslování musela být přepracována, aby klienti X mohli také podporovat přesměrování na „offscreen pixmaps“ při provádění přímého vykreslování. Běžní klienti X již respektovali přesměrování na samostatnou pixmapu poskytovanou serverem X jako cíl vykreslení - takzvanou pixmapu mimo obrazovku -, ale klienti DRI pokračovali v vykreslování přímo do sdíleného backbufferu, čímž efektivně obcházeli správce skládání oken.[11][13] Konečným řešením bylo změnit způsob, jakým DRI zpracovává vyrovnávací paměti pro vykreslování, což vedlo ke zcela odlišnému rozšíření DRI s novou sadou operací a také zásadním změnám v Správce přímého vykreslování.[3] Nová přípona byla pojmenována „DRI2“, i když se nejedná o novější verzi, ale o jinou příponu, která není ani kompatibilní s původním DRI - ve skutečnosti obě existovaly v rámci X Serveru po dlouhou dobu.
V DRI2 dostává každý klient DRI místo jedné sdílené (zpětné) vyrovnávací paměti vlastní privátní zadní vyrovnávací paměť[11][12] —Společně s jejich přidruženými hloubka a šablona vyrovnávací paměti - k vykreslení jeho okno obsah pomocí hardwarová akcelerace. Klient DRI pak swapy to s falešnou "přední nárazník ",[12] který používá správce skládání oken jako jeden ze zdrojů pro sestavení (sestavení) závěrečné vyrovnávací paměti závěrečné obrazovky, která se má vyměnit Interval VBLANK se skutečnou přední vyrovnávací pamětí.
Ke zpracování všech těchto nových vyrovnávacích pamětí musel Direct Rendering Manager začlenit nové funkce, konkrétně grafiku správce paměti. DRI2 byl původně vyvinut pomocí experimentu TTM správce paměti,[11][13] ale to bylo později přepsáno k použití KLENOT poté, co byl vybrán jako definitivní správce paměti DRM.[14] Nový model správy interní vyrovnávací paměti DRI2 také vyřešil dva hlavní úzká místa výkonu přítomná v původní implementaci DRI:
- Klienti DRI2 již nezamykají celé zařízení DRM, když je používají k vykreslování, protože každý klient nyní získá samostatnou vyrovnávací paměť vykreslení nezávislou na ostatních procesech.[12]
- Klienti DRI2 mohou přidělit své vlastní vyrovnávací paměti (s texturami, seznamy vrcholů, ...) ve videopaměti a udržovat je tak dlouho, jak chtějí, což výrazně snižuje video šířka pásma paměti spotřeba.
V DRI2 přidělování soukromých mezipamětí (zadní vyrovnávací paměť, falešná přední vyrovnávací paměť, hloubková vyrovnávací paměť, vyrovnávací paměť šablony, ...) pro okno provádí samotný X Server.[15][16] Klienti DRI načtou tyto vyrovnávací paměti, aby provedli vykreslení do okna voláním operací, jako je DRI2GetBuffers a DRI2GetBuffersWithFormat k dispozici v rozšíření DRI2.[3] Interně používá DRI2 Názvy klenotů —Typ globálního popisovače poskytovaného GEM API který umožňuje dvěma procesům přistupujícím k zařízení DRM odkazovat na stejnou vyrovnávací paměť - pro předávání „odkazů“ na tyto vyrovnávací paměti přes Protokol X11.[16] Důvod, proč X Server má na starosti přidělování vyrovnávacích pamětí vykreslovacích vyrovnávacích pamětí okna, je ten Rozšíření GLX umožňuje dělat více X klientům OpenGL kooperativní vykreslování ve stejném okně.[15] Tímto způsobem X Server spravuje celý životní cyklus vyrovnávacích pamětí vykreslení v průběhu celého procesu vykreslování a ví, kdy je může bezpečně recyklovat nebo zahodit. Když je provedena změna velikosti okna, je X Server také zodpovědný za přidělení nových vyrovnávacích pamětí vykreslování odpovídající nové velikosti okna a upozornění na změnu vykreslování klienta (ů) DRI do okna pomocí InvalidateBuffers události, aby načetli GEM názvy nových vyrovnávacích pamětí.[15]
Rozšíření DRI2 poskytuje klientům DRI další základní operace, například zjištění, které zařízení DRM a ovladač by měli používat (DRI2Connect) nebo ověření serverem X, aby bylo možné používat vykreslovací a vyrovnávací paměť zařízení DRM (DRI2Authenticate).[3] Prezentace vykreslených vyrovnávacích pamětí na obrazovce se provádí pomocí DRI2CopyRegion a DRI2SwapBuffers žádosti. DRI2CopyRegion lze použít k vytvoření kopie mezi falešnou přední vyrovnávací pamětí a skutečnou přední vyrovnávací pamětí, ale neposkytuje žádnou synchronizaci s intervalem vertikálního zatemnění, takže může způsobit trhání. DRI2SwapBuffers, na druhé straně provádí VBLANK synchronizovanou výměnu mezi zadní a přední vyrovnávací pamětí, pokud je podporována a obě vyrovnávací paměti mají stejnou velikost, nebo kopii (blit ) v opačném případě.[3][15]
DRI3
Přestože DRI2 bylo významným zlepšením oproti původnímu DRI, nové rozšíření také přineslo některé nové problémy.[15][16] V roce 2013 byla za účelem vyřešení těchto problémů vyvinuta třetí iterace infrastruktury přímého vykreslování známá jako DRI3.[17]
Hlavní rozdíly DRI3 ve srovnání s DRI2 jsou:
- Klienti DRI3 si přidělují své vyrovnávací paměti pro vykreslování, místo aby se při přidělování spoléhali na X Server - to byla metoda podporovaná DRI2.[15][16]
- DRI3 se zbaví starých nejistých KLENOT mechanismus sdílení vyrovnávací paměti založený na Názvy klenotů (globální úchyty GEM) pro předávání objektů vyrovnávací paměti mezi klientem DRI a serverem X ve prospěch jednoho bezpečnějšího a univerzálnějšího na základě PRIME DMA-BUF, který používá deskriptory souborů namísto.[15][16]
Alokace vyrovnávací paměti na straně klienta se přeruší GLX předpoklady v tom smyslu, že již není možné, aby se více aplikací GLX zobrazovalo kooperativně ve stejném okně. Pozitivní je, že skutečnost, že klient DRI má na starosti vlastní vyrovnávací paměti po celou dobu jejich životnosti, přináší mnoho výhod. Například je pro klienta DRI3 snadné zajistit, aby velikost vyrovnávacích pamětí pro vykreslení vždy odpovídala aktuální velikosti okna, a tím eliminovat artefakty kvůli nedostatku synchronizace velikostí vyrovnávací paměti mezi klientem a serverem, který sužoval změnu velikosti okna v DRI2.[15][16][18] Lepšího výkonu je také dosaženo, protože nyní klienti DRI3 ukládají další zpáteční cestu čekající na X Server k odeslání vyrovnávacích pamětí pro vykreslení.[16] Klienti DRI3, a zejména správci oken skladatelů, mohou využít výhod zachování starších vyrovnávacích pamětí předchozích rámců a jejich opětovného použití jako základu pro vykreslení pouze poškozených částí okna jako další optimalizaci výkonu.[15][16] Rozšíření DRI3 již není nutné upravovat, aby podporovalo nové konkrétní formáty vyrovnávacích pamětí, protože jsou nyní zpracovávány přímo mezi ovladačem klienta DRI a ovladačem jádra DRM.[15] Použití deskriptorů souborů na druhé straně umožňuje jádru provést bezpečné vyčištění jakéhokoli nepoužívaného objektu vyrovnávací paměti GEM - jediného bez odkazu na něj.[15][16]
Technicky se DRI3 skládá ze dvou různých rozšíření, rozšíření „DRI3“ a rozšíření „Present“.[17][19] Hlavním účelem rozšíření DRI3 je implementovat mechanismus sdílení přímých vykreslených vyrovnávacích pamětí mezi klienty DRI a X Serverem.[18][19][20] Klienti DRI přidělují a používají objekty vyrovnávacích pamětí GEM jako cíle vykreslování, zatímco X Server představuje tyto vyrovnávací paměti vykreslování pomocí typu objektu X11 s názvem „pixmap“. DRI3 poskytuje dvě operace, DRI3PixmapFromBuffer a DRI3BufferFromPixmap, jeden pro vytvoření pixmapy (v "prostoru X Serveru") z objektu vyrovnávací paměti GEM (v "klientském prostoru DRI") a druhý pro opak a získání objektu vyrovnávací paměti GEM z X pixmapy.[18][19][20] V těchto operacích DRI3 jsou objekty vyrovnávací paměti GEM předávány jako DMA-BUF deskriptory souborů místo jmen GEM. DRI3 také poskytuje způsob sdílení synchronizačních objektů mezi klientem DRI a X Serverem, což umožňuje jak serializovaný přístup ke sdílené vyrovnávací paměti.[19] Na rozdíl od DRI2, počáteční DRI3 Otevřeno operace — první, kdo musí každý klient DRI požádat, aby věděl, které zařízení DRM má použít - vrátí již otevřený deskriptor souboru do uzlu zařízení namísto názvu uzlu zařízení, přičemž jakýkoli požadovaný postup ověřování již předem provedl X Server.[18][19]
DRI3 neposkytuje žádný mechanismus pro zobrazení vykreslených vyrovnávacích pamětí na obrazovce, ale spoléhá se na jiné rozšíření, Současnost, dárek rozšíření.[20] Současnost, dárek je tak pojmenován, protože jeho hlavním úkolem je „prezentovat“ vyrovnávací paměti na obrazovce, což znamená, že zpracovává aktualizaci framebufferu pomocí obsahu vykreslených vyrovnávacích pamětí dodávaných klientskými aplikacemi.[19] Aktualizace obrazovky musí být provedeny ve správný čas, obvykle během Interval VBLANK aby se zabránilo artefaktům zobrazování, jako je trhání. Present také zpracovává synchronizaci aktualizací obrazovky s intervalem VBLANK.[21] Rovněž informuje klienta X o okamžiku, kdy se každá vyrovnávací paměť skutečně zobrazí na obrazovce pomocí událostí, takže klient může synchronizovat svůj proces vykreslování s aktuální obnovovací frekvencí obrazovky.
Současnost přijímá jakýkoli pixmap X jako zdroj pro aktualizaci obrazovky.[21] Vzhledem k tomu, že pixmapy jsou standardní objekty X, může Present být použit nejen klienty DRI3 provádějícími přímé vykreslování, ale také jakýmkoli způsobem vykreslování jakéhokoli klienta X na pixmapě.[18] Například většina existujícíchGL na základě GTK + a Qt dříve používané aplikace zdvojnásobeno vykreslování pixmap pomocí XRender. Tyto rozšíření mohou tyto aplikace také použít k dosažení efektivních a netrhajících se aktualizací obrazovky. To je důvod, proč byl Present vyvinut jako samostatné samostatné rozšíření, místo aby byl součástí DRI3.[18]
Kromě toho, že umožňuje synchronizaci s klienty jiných než GL X s VBLANK, přináší Present další výhody. Grafický výkon DRI3 je lepší, protože Present je při výměně vyrovnávacích pamětí efektivnější než DRI2.[19] Řada rozšíření OpenGL, která nebyla k dispozici s DRI2, je nyní podporována na základě nových funkcí poskytovaných programem Present.[19]
Současnost poskytuje klientům X dvě hlavní operace: aktualizaci oblasti okna pomocí části nebo celého obsahu pixmapy (PresentPixmap) a nastavit typ prezentačních událostí souvisejících s určitým oknem, o kterém chce klient být informován (PresentSelectInput).[19][21] Existují tři prezentační události, o kterých může okno upozornit klienta X: když probíhá operace prezentace - obvykle z volání na PresentPixmap- bylo dokončeno (PresentCompleteNotify), když pixmap používá a PresentPixmap provoz je připraven k opětovnému použití (PresentIdleNotify) a když se změní konfigurace okna - hlavně velikost okna - (PresentConfigureNotify).[19][21] Ať už PresentPixmap operace provádí přímou kopii (blit ) na přední nárazník nebo a vyměnit celé zadní vyrovnávací paměti s přední vyrovnávací pamětí je interním detailem implementace rozšíření rozšíření namísto explicitní volby klienta X, jak tomu bylo v DRI2.
Přijetí
![]() | Tato část musí být aktualizováno.Červen 2020) ( |
Bylo napsáno několik ovladačů DRI s otevřeným zdrojovým kódem, včetně ovladačů pro ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 až Voodoo5, Matrox G200 až G400, řada SiS 300, Intel i810 až i965, S3 Savage, PŘES Grafické čipové sady UniChrome a novinka pro Nvidia. Někteří prodejci grafiky napsali ovladače DRI uzavřeného zdroje, včetně ATI a Kyro.
Různé verze DRI byly implementovány různými operačními systémy, mimo jiné i Linuxové jádro, FreeBSD, NetBSD, OpenBSD, a OpenSolaris.
Dějiny
Projekt zahájili Jens Owen a Kevin E. Martin ze společnosti Precision Insight (financovali Křemíková grafika a červená čepice ).[1][22] Poprvé byl široce dostupný jako součást XFree86 4.0[1][23] a je nyní součástí X.Org Server. V současné době ji udržuje komunita svobodného softwaru.
Práce na DRI2 začaly na Summitu vývojářů X v roce 2007 od a Kristian Høgsberg návrh.[24][25] Sám Høgsberg napsal nové rozšíření DRI2 a jeho úpravy Mesa a GLX.[26] V březnu 2008 bylo DRI2 většinou hotové,[27][28][29] ale nemohlo se do toho dostat X.Org Server verze 1.5[14] a musel počkat na verzi 1.6 od února 2009.[30] Rozšíření DRI2 bylo oficiálně zahrnuto do vydání X11R7.5 z října 2009.[31] První veřejná verze protokolu DRI2 (2.0) byla oznámena v dubnu 2009.[32] Od té doby proběhlo několik revizí, nejnovější verze 2.8 z července 2012.[4]
Kvůli několika omezením DRI2 navrhli Keith Packard a Eric Anholt na konferenci vývojářů X.Org Developer 2012 novou příponu s názvem DRI-Next.[15] Rozšíření bylo znovu navrženo jako DRI3000 v Linux.conf.au 2013.[16][17] Rozšíření DRI3 a Present byla vyvinuta v průběhu roku 2013 a sloučena do vydání X.Org Server 1.15 z prosince 2013.[33][34] První a jediná verze protokolu DRI3 (1.0) byla vydána v listopadu 2013.[5]
2D ovladače uvnitř X server
Brzy DRI: Nastavení režimu stále provádí X zobrazovací server, což ho nutí běžet jako vykořenit
Nakonec veškerý přístup prochází Správce přímého vykreslování
V linuxovém jádře 3.12 vykreslení uzlů byly zavedeny; DRM a Ovladač KMS byly rozděleny. Wayland implementuje přímé vykreslování EGL
Viz také
Reference
- ^ A b C Owen, Jens. „Historie projektu DRI“. Wiki projektu DRI. Citováno 16. dubna 2016.
- ^ A b C Licence Mesa DRI / Informace o autorských právech - 3D grafická knihovna Mesa
- ^ A b C d E F Høgsberg, Kristian (4. září 2008). „Rozšíření DRI2 - verze 2.0“. X.Org. Citováno 29. května 2016.
- ^ A b Airlie, Dave (11. července 2012). „[OZNAM] dri2proto 2.8“. xorg-oznámit (Poštovní seznam).
- ^ A b C Packard, Keith (1. listopadu 2013). „[OZNAM] dri3proto 1.0“. xorg-oznámit (Poštovní seznam).
- ^ A b „Mesa 3D a Direct Rendering Infrastructure wiki“. Citováno 15. července 2014.
- ^ „DRI pro konzoly Framebuffer“. Citováno 4. ledna 2019.
- ^ Martin, Kevin E .; Faith, Rickard E .; Owen, Jens; Akin, Allen (11. května 1999). „Infrastruktura přímého vykreslování, nízkoúrovňový designový dokument“. Citováno 18. května 2016.
- ^ Owen, Jens; Martin, Kevin (11. května 1999). „Rozšíření DRI pro podporu přímého vykreslování - specifikace protokolu“. Citováno 18. května 2016.
- ^ Faith, Rickard E. (11. května 1999). „Správce přímého vykreslování: Podpora jádra pro infrastrukturu přímého vykreslování“. Citováno 18. května 2016.
- ^ A b C d E F Packard, Keith (21. července 2008). „Stav výstupu X červenec 2008“. Citováno 26. května 2016.
- ^ A b C d E F G Packard, Keith (24. dubna 2009). „Ostření zaměření ovladače Intel“. Citováno 26. května 2016.
- ^ A b Høgsberg, Kristian (8. srpna 2007). „Přesměrované přímé vykreslování“. Citováno 25. května 2016.
- ^ A b Høgsberg, Kristian (4. srpna 2008). "Zálohování DRI2 ze serveru 1.5". xorg (Poštovní seznam).
- ^ A b C d E F G h i j k l Packard, Keith (28. září 2012). „Myšlenky na DRI.Next“. Citováno 26. května 2016.
- ^ A b C d E F G h i j Willis, Nathan (11. února 2013). „LCA: X-men mluví“. LWN.net. Citováno 26. května 2016.
- ^ A b C Packard, Keith (19. února 2013). „DRI3000 - ještě lepší přímé vykreslování“. Citováno 26. května 2016.
- ^ A b C d E F Packard, Keith (4. června 2013). „Dokončení rozšíření DRI3“. Citováno 31. května 2016.
- ^ A b C d E F G h i j Edge, Jake (9. října 2013). "DRI3 a současnost". LWN.net. Citováno 26. května 2016.
- ^ A b C Packard, Keith (4. června 2013). „Rozšíření DRI3 - verze 1.0“. Citováno 30. května 2016.
- ^ A b C d Packard, Keith (6. června 2013). „Současné rozšíření - verze 1.0“. Citováno 1. června 2016.
- ^ Owen, Jens; Martin, Kevin E. (15. září 1998). „Vícekanálová architektura přímého vykreslování pro 3D“. Citováno 16. dubna 2016.
- ^ „Poznámky k verzi pro XFree86 4.0“. Projekt XFree86. 7. března 2000. Citováno 16. dubna 2016.
- ^ „Summit vývojářů X 2007 - poznámky“. X.Org. Citováno 7. března 2016.
- ^ Høgsberg, Kristian (3. října 2007). „Wiki stránka DRI2 Design“. xorg (Poštovní seznam).
- ^ Høgsberg, Kristian (4. února 2008). "Plány na sloučení práce DRI2". xorg (Poštovní seznam).
- ^ Høgsberg, Kristian (15. února 2008). „DRI2 commit“. xorg (Poštovní seznam).
- ^ Høgsberg, Kristian (31. března 2008). „DRI2 direct rendering“. xorg (Poštovní seznam).
- ^ Høgsberg, Kristian (31. března 2008). „DRI2 Direct Rendering“. Citováno 20. dubna 2016.
- ^ "Větev 1.6 serveru". X.org. Citováno 7. února 2015.
- ^ „Poznámky k verzi X11R7.5“. X.Org. Citováno 20. dubna 2016.
- ^ Høgsberg, Kristian (20. dubna 2009). „[OZNAM] dri2proto 2.0“. xorg-oznámit (Poštovní seznam).
- ^ Packard, Keith. „[OZNAM] xorg-server 1.14.99.901“. X.org. Citováno 9. února 2015.
- ^ Larabel, Michael. „Verze X.Org Server 1.15 má několik nových funkcí“. Phoronix. Citováno 9. února 2015.
externí odkazy
- Domovská stránka projektu Direct Rendering Infrastructure
- Aktuální dokumenty se specifikacemi (vždy aktualizovány na nejnovější verzi):
- Rozšíření DRI2 (Kristian Høgsberg, 2008)
- Rozšíření DRI3 (Keith Packard, 2013)
- Současné rozšíření (Keith Packard, 2013)