DRI-2.0
OriginalautorKristian Høgsberg et al.
Entwicklerfreedesktop.org
Freigeben4. September 2008 [ 3 ] ( 04.09.2008 )
Stabile Version
2.8 / 11. Juli 2012 [ 4 ] ( 11.07.2012 )
Geschrieben inC
PlattformPOSIX
TypFramework / API
LizenzMIT- und andere Lizenzen [ 2 ]
Webseitedri.freedesktop.org​​
DRI-3.0
OriginalautorKeith Packard et al.
Entwicklerfreedesktop.org
Freigeben1. November 2013 [ 5 ] ( 2013-11-01 )
Stabile Version
1.0 / 1. November 2013 [ 5 ] ( 2013-11-01 )
Geschrieben inC
PlattformPOSIX
TypFramework / API
LizenzMIT- und andere Lizenzen [ 2 ]
Webseitedri.freedesktop.org​​
Es gibt zwei Grafikhardwaretreiber: Einer befindet sich im X- Display-Server . Dieser Treiber wurde bereits in mehreren Versionen entwickelt. Die aktuelle Version teilt ihn in zwei Teile auf: DIX (Geräteunabhängiges X) und DDX (Geräteabhängiges X).
Glamor wird den X-Server vereinfachen , und libGL-fglrx-glx könnte die libDRM des Open-Source-Treibers von Radeon anstelle des proprietären Binär-Blobs verwenden .
Die Rendering- Berechnungen werden über OpenGL an die GPU ausgelagert und in Echtzeit durchgeführt. Das DRI regelt den Zugriff und die Buchhaltung.

Die Direct Rendering Infrastructure ( DRI ) ist das Framework des modernen Linux -Grafikstacks, das es unprivilegierten Benutzerprogrammen ermöglicht, Befehle an die Grafikhardware zu senden , ohne mit anderen Programmen in Konflikt zu geraten. [ 6 ] DRI dient hauptsächlich der Hardwarebeschleunigung der Mesa -Implementierung von OpenGL . Darüber hinaus wurde DRI so angepasst, dass OpenGL-Beschleunigung auf einer Framebuffer-Konsole ohne laufenden Display-Server möglich ist . [ 7 ]

Die DRI-Implementierung ist über den X-Server und seine zugehörigen Client-Bibliotheken, Mesa 3D und das Direct Rendering Manager- Kernel-Subsystem verteilt. [ 6 ] Der gesamte Quellcode ist Open-Source-Software .

Überblick

In der klassischen Architektur des X Window Systems hat nur der X-Server exklusiven Zugriff auf die Grafikhardware und ist somit für das eigentliche Rendern im Framebuffer zuständig. X-Clients kommunizieren lediglich mit dem X-Server, um Rendering-Befehle zu senden. Diese Befehle sind hardwareunabhängig. Das bedeutet, dass das X11-Protokoll eine API bereitstellt , die das Grafikgerät abstrahiert, sodass die X-Clients die Details der zugrundeliegenden Hardware weder kennen noch berücksichtigen müssen. Jeglicher hardwarespezifischer Code befindet sich im Device Dependent X (DX) , dem Teil des X-Servers, der die verschiedenen Grafikkarten bzw. Grafikadapter verwaltet und oft auch als Video- oder Grafiktreiber bezeichnet wird .

Der Aufstieg des 3D-Renderings hat die Grenzen dieser Architektur aufgezeigt. 3D-Grafikanwendungen erzeugen große Mengen an Befehlen und Daten, die alle zur Darstellung an den X-Server gesendet werden müssen. Mit zunehmender Interprozesskommunikation (IPC) zwischen X-Client und X-Server verschlechterte sich die 3D-Rendering-Performance so stark, dass die Entwickler der X-Treiber zu dem Schluss kamen, dass eine neue, IPC-freie Architektur erforderlich ist, um die 3D-Hardwarefunktionen der neuesten Grafikkarten optimal zu nutzen. X-Clients sollten direkten Zugriff auf die Grafikhardware haben, anstatt auf einen anderen Prozess angewiesen zu sein, wodurch der gesamte IPC-Overhead entfällt. Dieser Ansatz wird als „direktes Rendering“ bezeichnet, im Gegensatz zum „indirekten Rendering“ der klassischen X-Architektur. Die Direct Rendering Infrastructure wurde ursprünglich entwickelt, um jedem X-Client die Durchführung von 3D-Rendering mit diesem „direkten Rendering“-Ansatz zu ermöglichen.

Nichts spricht dagegen, DRI zur Implementierung von beschleunigtem 2D-Direktrendering innerhalb eines X-Clients zu verwenden. [ 3 ] Bisher bestand schlichtweg keine Notwendigkeit dafür, da die Leistung des indirekten 2D-Renderings ausreichend war.

Softwarearchitektur

Die grundlegende Architektur der Direct Rendering Infrastructure umfasst drei Hauptkomponenten: [ 8 ]

  • Der DRI-Client – ​​beispielsweise ein X-Client, der „Direct Rendering“ durchführt – benötigt einen hardwarespezifischen Treiber, der die vorhandene Grafikkarte oder den Grafikadapter ansteuern kann, um darauf zu rendern. Diese DRI-Treiber werden üblicherweise als Shared Libraries bereitgestellt , mit denen der Client dynamisch verknüpft wird . Da DRI für die Nutzung von 3D-Grafikhardware konzipiert wurde, werden die Bibliotheken den Clients normalerweise als hardwarebeschleunigte Implementierungen einer 3D-API wie OpenGL präsentiert , die entweder vom 3D-Hardwarehersteller selbst oder von einem Drittanbieter wie dem freien Softwareprojekt Mesa 3D bereitgestellt werden .
  • Der X-Server stellt eine X11-Protokollerweiterung bereit – die DRI-Erweiterung –, die von den DRI-Clients zur Koordination mit dem Fenstersystem und dem DDX-Treiber verwendet wird. [ 9 ] Als Teil des DDX-Treibers ist es üblich, dass der X-Server-Prozess dynamisch auf denselben DRI-Treiber wie die DRI-Clients zugreift, um hardwarebeschleunigtes 3D-Rendering für die X-Clients bereitzustellen, die die GLX- Erweiterung für indirektes Rendering nutzen (z. B. entfernte X-Clients, die kein direktes Rendering verwenden können). Für 2D-Rendering muss der DDX-Treiber auch die DRI-Clients berücksichtigen, die dasselbe Grafikgerät verwenden.
  • Der Zugriff auf die Grafikkarte bzw. den Grafikadapter wird durch eine Kernelkomponente namens Direct Rendering Manager (DRM) geregelt. [ 10 ] Sowohl der DDX-Treiber des X-Servers als auch die DRI-Treiber der X-Clients müssen DRM verwenden, um auf die Grafikhardware zuzugreifen. DRM synchronisiert die gemeinsam genutzten Ressourcen der Grafikhardware – wie beispielsweise die Befehlswarteschlange, die Kartenregister, den Videospeicher und die DMA-Engines – und stellt so sicher, dass sich die gleichzeitigen Zugriffe mehrerer konkurrierender Benutzerprozesse nicht gegenseitig beeinträchtigen. DRM dient außerdem als grundlegende Sicherheitsmaßnahme, die verhindert, dass X-Clients über den für das 3D-Rendering erforderlichen Zugriff auf die Hardware hinausgehen.

DRI1

In der ursprünglichen DRI-Architektur gab es aufgrund der Speicherkapazität der damaligen Grafikkarten nur eine einzige Instanz des Bildschirm -Frontbuffers und -Backbuffers (sowie des zusätzlichen Tiefen- und Schablonenpuffers ), die von allen DRI-Clients und dem X-Server gemeinsam genutzt wurde. [ 11 ] [ 12 ] Alle Clients renderten direkt in den Backbuffer, der im Rahmen des vertikalen Austastintervalls mit dem Frontbuffer ausgetauscht wurde . [ 11 ] Um in den Backbuffer zu rendern, musste ein DRI-Prozess sicherstellen, dass das Rendering auf den für sein Fenster reservierten Bereich beschränkt wurde . [ 11 ] [ 12 ]

Die Synchronisierung mit dem X-Server erfolgte über Signale und einen gemeinsamen Speicherpuffer namens SAREA. [ 12 ] Der Zugriff auf das DRM-Gerät war exklusiv, sodass jeder DRI-Client es zu Beginn eines Rendering- Vorgangs sperren musste . Andere Nutzer des Geräts – einschließlich des X-Servers – waren in der Zwischenzeit blockiert und mussten warten, bis die Sperre am Ende des aktuellen Rendering-Vorgangs aufgehoben wurde, selbst wenn kein Konflikt zwischen den beiden Vorgängen bestand. [ 12 ] Ein weiterer Nachteil war, dass Vorgänge die Speicherbelegung nicht beibehielten, nachdem der aktuelle DRI-Prozess seine Sperre auf dem Gerät aufgehoben hatte. Dadurch gingen alle in den Grafikspeicher hochgeladenen Daten, wie z. B. Texturen , für nachfolgende Vorgänge verloren, was die Grafikleistung erheblich beeinträchtigte.

Heutzutage gilt DRI1 als völlig veraltet und darf nicht mehr verwendet werden.

DRI2

Aufgrund der zunehmenden Beliebtheit von Compositing-Fenstermanagern wie Compiz musste die Direct Rendering Infrastructure (DRI) überarbeitet werden, um X-Clients die Umleitung auf „Offscreen-Pixmaps“ beim direkten Rendering zu ermöglichen. Reguläre X-Clients berücksichtigten bereits die Umleitung auf eine separate, vom X-Server bereitgestellte Pixmap als Renderziel – die sogenannte Offscreen-Pixmap –, DRI-Clients renderten jedoch weiterhin direkt in den gemeinsamen Backbuffer und umgingen so den Compositing-Fenstermanager. [ 11 ] [ 13 ] Die endgültige Lösung bestand darin, die Handhabung der Renderpuffer durch DRI zu ändern. Dies führte zu einer völlig neuen DRI-Erweiterung mit neuen Operationen und auch zu grundlegenden Änderungen am Direct Rendering Manager . [ 3 ] Die neue Erweiterung erhielt den Namen „DRI2“, obwohl es sich nicht um eine neuere Version, sondern um eine eigenständige Erweiterung handelt, die nicht einmal mit dem ursprünglichen DRI kompatibel ist – tatsächlich existierten beide lange Zeit parallel im X-Server.

In DRI2 erhält jeder DRI-Client anstelle eines gemeinsamen (Back-)Puffers einen eigenen privaten Back-Puffer [ 11 ] [ 12 ] – zusammen mit den zugehörigen Tiefen- und Schablonenpuffern –, um seinen Fensterinhalt mithilfe der Hardwarebeschleunigung zu rendern . Der DRI-Client tauscht diesen dann gegen einen simulierten „ Front-Puffer “ [ 12 ] aus , der vom Compositing Window Manager als eine der Quellen verwendet wird, um den endgültigen Bildschirm-Back-Puffer zu erstellen, der im VBLANK-Intervall mit dem eigentlichen Front-Puffer ausgetauscht wird.

Um all diese neuen Puffer zu verwalten, musste der Direct Rendering Manager (DRM) neue Funktionen, insbesondere einen Grafikspeichermanager, integrieren . DRI2 wurde ursprünglich mit dem experimentellen TTM- Speichermanager entwickelt [ 11 , 13 ] , später jedoch auf GEM umgestellt, nachdem dieser als endgültiger DRM-Speichermanager ausgewählt worden war [ 14 ] . Das neue interne Pufferverwaltungsmodell von DRI2 behob zudem zwei wesentliche Leistungsengpässe der ursprünglichen DRI-Implementierung:

  • DRI2-Clients sperren beim Rendern nicht mehr das gesamte DRM-Gerät, da nun jeder Client einen separaten Renderpuffer erhält, der von den anderen Prozessen unabhängig ist. [ 12 ]
  • DRI2-Clients können ihre eigenen Puffer (mit Texturen, Vertexlisten usw.) im Videospeicher anlegen und diese beliebig lange behalten, was den Verbrauch der Videospeicherbandbreite erheblich reduziert .

In DRI2 erfolgt die Zuweisung der privaten Offscreen-Puffer (Backbuffer, Fake-Frontbuffer, Tiefenpuffer, Stencil-Puffer usw.) für ein Fenster durch den X-Server selbst. [ 15 ] [ 16 ] DRI-Clients rufen diese Puffer ab, um das Rendering im Fenster durchzuführen, indem sie Operationen wie DRI2GetBuffers und DRI2GetBuffersWithFormat aufrufen , die in der DRI2-Erweiterung verfügbar sind. [ 3 ] Intern verwendet DRI2 GEM-Namen – eine Art globaler Handle der GEM-API , die es zwei Prozessen ermöglicht, die auf ein DRM-Gerät zugreifen, auf denselben Puffer zu verweisen – um „Referenzen“ auf diese Puffer über das X11-Protokoll zu übergeben . [ 16 ] Der Grund dafür, dass der X-Server für die Pufferzuweisung der Renderpuffer eines Fensters zuständig ist, liegt darin, dass die GLX-Erweiterung es mehreren X-Clients ermöglicht, OpenGL- Rendering im selben Fenster kooperativ durchzuführen . [ 15 ] Auf diese Weise verwaltet der X-Server den gesamten Lebenszyklus der Renderpuffer während des Rendering-Prozesses und weiß, wann er sie sicher wiederverwenden oder verwerfen kann. Bei einer Fenstergrößenänderung ist der X-Server außerdem dafür verantwortlich, neue Renderpuffer entsprechend der neuen Fenstergröße zuzuweisen und die Änderung den DRI-Client(s), die in das Fenster rendern, mittels eines InvalidateBuffers-Ereignisses mitzuteilen, damit diese die GEM-Namen der neuen Puffer abrufen können. [ 15 ]

Die DRI2-Erweiterung stellt weitere Kernfunktionen für DRI-Clients bereit, beispielsweise die Ermittlung des zu verwendenden DRM-Geräts und -Treibers ( DRI2Connect ) oder die Authentifizierung durch den X-Server, um die Rendering- und Pufferfunktionen des DRM-Geräts nutzen zu können ( DRI2Authenticate ). [ 3 ] Die Darstellung der gerenderten Puffer auf dem Bildschirm erfolgt mithilfe der Anfragen DRI2CopyRegion und DRI2SwapBuffers . DRI2CopyRegion kann zum Kopieren zwischen dem simulierten und dem tatsächlichen Frontpuffer verwendet werden, bietet jedoch keine Synchronisierung mit dem vertikalen Austastintervall (VBLANK), was zu Bildfehlern (Tearing) führen kann . DRI2SwapBuffers hingegen führt einen VBLANK-synchronisierten Tausch zwischen Back- und Frontpuffer durch, sofern dies unterstützt wird und beide Puffer die gleiche Größe haben, andernfalls eine Kopie ( Blit ). [ 3 ] [ 15 ]

DRI3

Obwohl DRI2 eine deutliche Verbesserung gegenüber dem ursprünglichen DRI darstellte, brachte die neue Erweiterung auch einige neue Probleme mit sich. [ 15 ] [ 16 ] Um diese Probleme zu beheben, wurde 2013 eine dritte Iteration der Direct Rendering Infrastructure namens DRI3 entwickelt. [ 17 ]

Die wichtigsten Unterschiede zwischen DRI3 und DRI2 sind:

  • DRI3-Clients allokieren ihre Renderpuffer selbst, anstatt sich wie bei DRI2 auf die Allokation durch den X-Server zu verlassen. [ 15 ] [ 16 ]
  • DRI3 ersetzt den alten, unsicheren GEM- Puffer-Sharing-Mechanismus, der auf GEM-Namen (globalen GEM-Handles) basiert, durch einen sichereren und vielseitigeren Mechanismus auf Basis von PRIME DMA-BUFs , der Dateideskriptoren verwendet . [ 15 ] [ 16 ]

Die clientseitige Pufferverwaltung bricht mit den GLX- Annahmen, da mehrere GLX-Anwendungen nicht mehr gleichzeitig im selben Fenster rendern können. Positiv ist jedoch, dass der DRI-Client seine Puffer während ihrer gesamten Lebensdauer selbst verwaltet. So kann der DRI3-Client beispielsweise problemlos sicherstellen, dass die Größe der Renderpuffer stets der aktuellen Fenstergröße entspricht und dadurch die Artefakte beseitigen, die durch die fehlende Synchronisierung der Puffergrößen zwischen Client und Server beim Ändern der Fenstergröße in DRI2 auftraten. [ 15 ] [ 16 ] [ 18 ] Eine bessere Performance wird auch dadurch erzielt, dass DRI3-Clients den zusätzlichen Roundtrip zum Warten auf die Renderpuffer des X-Servers einsparen. [ 16 ] DRI3-Clients, insbesondere Compositor-Fenstermanager, können ältere Puffer vorheriger Frames speichern und als Grundlage für das Rendern nur der beschädigten Fensterteile verwenden, was die Performance weiter optimiert. [ 15 ] [ 16 ] Die DRI3-Erweiterung muss nicht mehr angepasst werden, um neue Pufferformate zu unterstützen, da diese nun direkt zwischen dem DRI-Client-Treiber und dem DRM-Kernel-Treiber verarbeitet werden. [ 15 ] Die Verwendung von Dateideskriptoren ermöglicht es dem Kernel hingegen, ungenutzte GEM-Pufferobjekte – also solche, auf die keine Referenz mehr existiert – sicher zu entfernen. [ 15 ] [ 16 ]

Technisch gesehen besteht DRI3 aus zwei verschiedenen Erweiterungen: der „DRI3“-Erweiterung und der „Present“-Erweiterung. [ 17 ] [ 19 ] Die DRI3-Erweiterung dient hauptsächlich dazu, den Mechanismus zum gemeinsamen Nutzen von direkt gerenderten Puffern zwischen DRI-Clients und dem X-Server zu implementieren. [ 18 ] [ 19 ] [ 20 ] DRI-Clients allokieren und verwenden GEM-Pufferobjekte als Rendering-Ziele, während der X-Server diese Renderpuffer mithilfe eines X11-Objekts namens „Pixmap“ repräsentiert. DRI3 bietet zwei Operationen: DRI3PixmapFromBuffer und DRI3BufferFromPixmap . Die erste Operation erstellt ein Pixmap (im X-Server-Bereich) aus einem GEM-Pufferobjekt (im DRI-Client-Bereich), die zweite wandelt es in ein GEM-Pufferobjekt um. [ 18 ] [ 19 ] [ 20 ] Bei diesen DRI3-Operationen werden GEM-Pufferobjekte als DMA-BUF -Dateideskriptoren anstelle von GEM-Namen übergeben. DRI3 bietet außerdem eine Möglichkeit, Synchronisierungsobjekte zwischen dem DRI-Client und dem X-Server auszutauschen und so einen serialisierten Zugriff auf den gemeinsamen Puffer zu ermöglichen. [ 19 ] Im Gegensatz zu DRI2 gibt die initiale DRI3Open -Operation – die jeder DRI-Client als erste anfordern muss, um das zu verwendende DRM-Gerät zu ermitteln – einen bereits geöffneten Dateideskriptor für den Geräteknoten anstelle des Dateinamens des Geräteknotens zurück, wobei die erforderliche Authentifizierung bereits vom X-Server durchgeführt wurde. [ 18 ] [ 19 ]

DRI3 bietet keinen Mechanismus zur Anzeige der gerenderten Puffer auf dem Bildschirm, sondern verwendet hierfür die Erweiterung Present . [ 20 ] Present ist so benannt, weil seine Hauptaufgabe darin besteht, Puffer auf dem Bildschirm darzustellen. Das bedeutet, dass es die Aktualisierung des Framebuffers anhand der von Clientanwendungen gelieferten Inhalte der gerenderten Puffer übernimmt. [ 19 ] Bildschirmaktualisierungen müssen zum richtigen Zeitpunkt, üblicherweise während des VBLANK-Intervalls, erfolgen , um Darstellungsartefakte wie Tearing zu vermeiden . Present synchronisiert die Bildschirmaktualisierungen auch mit dem VBLANK-Intervall. [ 21 ] Außerdem informiert es den X-Client mithilfe von Ereignissen darüber, wann jeder Puffer tatsächlich auf dem Bildschirm angezeigt wird, sodass der Client seinen Rendering-Prozess mit der aktuellen Bildschirmaktualisierungsrate synchronisieren kann.

Present accepts any X pixmap as the source for a screen update.[21] Since pixmaps are standard X objects, Present can be used not only by DRI3 clients performing direct rendering, but also by any X client rendering on a pixmap by any means.[18] For example, most existing non-GL based GTK+ and Qt applications used to do double buffered pixmap rendering using XRender. The Present extension can also be used by these applications to achieve efficient and non-tearing screen updates. This is the reason why Present was developed as a separate standalone extension instead of being part of DRI3.[18]

Apart from allowing non-GL X clients to synchronize with VBLANK, Present brings other advantages. DRI3 graphics performance is better because Present is more efficient than DRI2 in swapping buffers.[19] A number of OpenGL extensions that weren't available with DRI2 are now supported based on new features provided by Present.[19]

Present provides two main operations to X clients: update a region of a window using part of or all the contents of a pixmap (PresentPixmap) and set the type of presentation events related to a certain window that the client wants to be notified about (PresentSelectInput).[19][21] There are three presentation events about which a window can notify an X client: when an ongoing presentation operation —normally from a call to PresentPixmap— has been completed (PresentCompleteNotify), when a pixmap used by a PresentPixmap operation is ready to be reused (PresentIdleNotify) and when the window configuration —mostly window size— changes (PresentConfigureNotify).[19][21] Whether a PresentPixmap operation performs a direct copy (blit) onto the front buffer or a swap of the entire back buffer with the front buffer is an internal detail of the Present extension implementation, instead of an explicit choice of the X client as it was in DRI2.

Adoption

Es wurden mehrere Open-Source-DRI-Treiber entwickelt, unter anderem für ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 bis Voodoo5, Matrox G200 bis G400, SiS 300-Serie, Intel i810 bis i965, S3 Savage, VIA UniChrome-Grafikchipsätze und nouveau für Nvidia . Einige Grafikkartenhersteller, darunter ATI und PowerVR Kyro, haben proprietäre DRI-Treiber entwickelt .

Die verschiedenen Versionen von DRI wurden von verschiedenen Betriebssystemen implementiert, unter anderem vom Linux-Kernel , FreeBSD , NetBSD , OpenBSD und OpenSolaris .

Geschichte

Das Projekt wurde von Jens Owen und Kevin E. Martin von Precision Insight (finanziert von Silicon Graphics und Red Hat ) initiiert . [ 1 ] [ 22 ] Es wurde erstmals im Rahmen von XFree86 4.0 [ 1 ] [ 23 ] allgemein verfügbar gemacht und ist nun Teil des X.Org-Servers . Es wird aktuell von der Open-Source-Community weiterentwickelt .

Die Arbeiten an DRI2 begannen auf dem X Developers' Summit 2007 mit einem Vorschlag von Kristian Høgsberg . [ 24 ] [ 25 ] Høgsberg selbst schrieb die neue DRI2-Erweiterung und die Modifikationen an Mesa und GLX . [ 26 ] Im März 2008 war DRI2 weitgehend fertiggestellt, [ 27 ] [ 28 ] [ 29 ] konnte aber nicht in X.Org Server Version 1.5 [ 14 ] integriert werden und musste bis Version 1.6 vom Februar 2009 warten. [ 30 ] Die DRI2-Erweiterung wurde offiziell in die X11R7.5-Version vom Oktober 2009 aufgenommen. [ 31 ] Die erste öffentliche Version des DRI2-Protokolls (2.0) wurde im April 2009 angekündigt. [ 32 ] Seitdem gab es mehrere Überarbeitungen, die aktuellste ist Version 2.8 vom Juli 2012. [ 4 ]

Aufgrund verschiedener Einschränkungen von DRI2 wurde auf der X.Org Developer's Conference 2012 von Keith Packard und Emma Anholt eine neue Erweiterung namens DRI-Next vorgeschlagen. [ 15 ] Diese Erweiterung wurde auf der Linux.conf.au 2013 als DRI3000 erneut vorgestellt. [ 16 ] [ 17 ] Die Erweiterungen DRI3 und Present wurden im Laufe des Jahres 2013 entwickelt und ab Dezember 2013 in die X.Org Server-Version 1.15 integriert. [ 33 ] [ 34 ] Die erste und bisher einzige Version des DRI3-Protokolls (1.0) wurde im November 2013 veröffentlicht. [ 5 ]

Siehe auch

Referenzen

  1. ^ a b c Owen, Jens. „Die Geschichte des DRI-Projekts“ . DRI-Projekt-Wiki . Abgerufen am 16. April 2016 .
  2. ^ a b c Mesa DRI Lizenz- / Urheberrechtsinformationen - Die Mesa 3D-Grafikbibliothek
  3. ^ a b c d e f Høgsberg, Kristian (4. September 2008). „Die DRI2-Erweiterung – Version 2.0“ . X.Org . Abgerufen am 29. Mai 2016 .
  4. ^ a b Airlie, Dave (11. Juli 2012). "[ANNOUNCE] dri2proto 2.8" . xorg-announce (Mailingliste).
  5. ^ a b c Packard, Keith (1. November 2013). "[ANNOUNCE] dri3proto 1.0" . xorg-announce (Mailingliste).
  6. ^ a b „Mesa 3D and Direct Rendering Infrastructure wiki“ . Abgerufen am 15. Juli 2014 .
  7. ^ „DRI für Framebuffer-Konsolen“ . Abgerufen am 4. Januar 2019 .
  8. ^ Martin, Kevin E.; Faith, Rickard E.; Owen, Jens; Akin, Allen (11. Mai 1999). „Direct Rendering Infrastructure, Low-Level Design Document“ . Archiviert vom Original am 23. Juli 2016. Abgerufen am 18. Mai 2016 .
  9. ^ Owen, Jens; Martin, Kevin (11. Mai 1999). „DRI-Erweiterung zur Unterstützung von Direct Rendering – Protokollspezifikation“ . Abgerufen am 18. Mai 2016 .
  10. ^ Faith, Rickard E. (11. Mai 1999). „Der Direct Rendering Manager: Kernel-Unterstützung für die Direct Rendering-Infrastruktur“ . Archiviert vom Original am 21. Mai 2024. Abgerufen am 18. Mai 2016 .
  11. ^ a b c d e f Packard, Keith (21. Juli 2008). „X output status july 2008“ . Abgerufen am 26. Mai 2016 .
  12. ^ a b c d e f g Packard, Keith (24. April 2009). „Sharpening the Intel Driver Focus“ . Abgerufen am 26. Mai 2016 .
  13. ^ Høgsberg , Kristian (8. August 2007) . „Umgeleitetes direktes Rendering“ . Abgerufen am 25. Mai 2016 .
  14. ^ a b Høgsberg, Kristian (4. August 2008). "Backing out DRI2 from server 1.5" . xorg (Mailing list).
  15. ^ a b c d e f g h i j k l Packard, Keith (28. September 2012). „Gedanken zu DRI.Next“ . Abgerufen am 26. Mai 2016 .
  16. ^ a b c d e f g h i j Willis, Nathan (11. Februar 2013). „LCA: Die X-Men sprechen“ . LWN.net . Abgerufen am 26. Mai 2016 .
  17. ^ a b c Packard, Keith (19. Februar 2013). „DRI3000 – Noch besseres Direct Rendering“ . Abgerufen am 26. Mai 2016 .
  18. ^ a b c d e f Packard, Keith (4. Juni 2013). „Completing the DRI3 Extension“ . Abgerufen am 31. Mai 2016 .
  19. ^ a b c d e f g h i j Edge, Jake (9. Oktober 2013). „DRI3 und Gegenwart“ . LWN.net . Abgerufen am 26. Mai 2016 .
  20. ^ a b c Packard, Keith (4. Juni 2013). „Die DRI3-Erweiterung – Version 1.0“ . Abgerufen am 30. Mai 2016 .
  21. ^ a b c d Packard, Keith (6. Juni 2013). „The Present Extension – Version 1.0“ . Abgerufen am 1. Juni 2016 .
  22. ^ Owen, Jens; Martin, Kevin E. (15. September 1998). „Eine Multipipe-Direktrendering-Architektur für 3D“ . Archiviert vom Original am 3. März 2016. Abgerufen am 16. April 2016 .
  23. ^ „Versionshinweise für XFree86 4.0“ . XFree86-Projekt . 7. März 2000. Abgerufen am 16. April 2016 .
  24. ^ „X Developers' Summit 2007 – Notizen“ . X.Org . Abgerufen am 7. März 2016 .
  25. ^ Høgsberg, Kristian (3. Oktober 2007). „DRI2 Design Wiki-Seite“ . xorg (Mailingliste).
  26. ^ Høgsberg, Kristian (4. Februar 2008). „Pläne zur Zusammenführung der DRI2-Arbeit“ . xorg (Mailingliste).
  27. ^ Høgsberg, Kristian (15. Februar 2008). „DRI2 festgeschrieben“ . xorg (Mailingliste).
  28. ^ Høgsberg, Kristian (31. März 2008). „DRI2-Direktrendering“ . xorg (Mailingliste).
  29. ^ Høgsberg, Kristian (31. März 2008). „DRI2 Direct Rendering“ . Abgerufen am 20. April 2016 .
  30. ^ „Server 1.6 branch“ . X.org . Abgerufen am 7. Februar 2015 .
  31. ^ „Versionshinweise für X11R7.5“ . X.Org . Abgerufen am 20. April 2016 .
  32. ^ Høgsberg, Kristian (20. April 2009). „[ANKÜNDIGEN] dri2proto 2.0“ . xorg-announce (Mailingliste).
  33. ^ Packard, Keith (November 2013). "[ANNOUNCE] xorg-server 1.14.99.901" . X.org . Abgerufen am 9. Februar 2015 .
  34. ^ Larabel, Michael. „X.Org Server 1.15 Release Has Several New Features“ . Phoronix . Abgerufen am 9. Februar 2015 .