Mesa (Computergrafik) - Mesa (computer graphics)

Mesa

Originalautor(en)	Brian Paul
Entwickler	Aktuell: Intel , AMD , VMware Früher: Tungsten Graphics
Erstveröffentlichung	Februar 1995
Stabile Version	21.2.3  / 29. September 2021 ; Vor 18 Tagen ( 29. September 2021 )
Repository
Geschrieben in	C , C++ , Assemblersprache
Betriebssystem	Plattformübergreifend ( BSDs , Haiku , Linux usw.)
Typ	Grafikbibliothek
Lizenz	MIT-Lizenz
Webseite	Mesa3D .org

Mesa , auch Mesa3D und The Mesa 3D Graphics Library genannt , ist eine Open-Source-Softwareimplementierung von OpenGL , Vulkan und anderen Grafik- API- Spezifikationen. Mesa übersetzt diese Spezifikationen in herstellerspezifische Grafikhardwaretreiber.

Seine wichtigsten Benutzer sind zwei Grafiktreiber, die hauptsächlich von Intel und AMD für ihre jeweilige Hardware entwickelt und finanziert werden (AMD fördert ihre Mesa-Treiber Radeon und RadeonSI gegenüber dem veralteten AMD Catalyst , und Intel hat nur den Mesa-Treiber unterstützt). Proprietäre Grafiktreiber (z. B. Nvidia GeForce-Treiber und Catalyst) ersetzen Mesa vollständig und bieten ihre eigene Implementierung einer Grafik-API. Ein Open-Source-Projekt zum Schreiben eines Mesa-Nvidia-Treibers namens Nouveau wird hauptsächlich von der Community entwickelt.

Neben 3D - Anwendungen wie Spiele, moderner Display - Server ( X.org des Zauber oder Wayland ‚s Weston ) Verwendung von OpenGL / EGL ; daher laufen alle Grafiken normalerweise über Mesa.

Mesa wird von freedesktop.org gehostet und wurde im August 1993 von Brian Paul initiiert , der noch immer im Projekt aktiv ist. Mesa wurde in der Folge weit verbreitet und enthält heute zahlreiche Beiträge verschiedener Einzelpersonen und Unternehmen weltweit, einschließlich der Grafikhardwarehersteller der Khronos-Gruppe , die die OpenGL-Spezifikation verwalten. Auch bei Linux wurde die Entwicklung teilweise durch Crowdfunding vorangetrieben .

Überblick

Videospiele lagern Rendering-Berechnungen in Echtzeit über OpenGL an die GPU aus . Shader werden in OpenGL Shading Language oder SPIR-V geschrieben und auf der CPU kompiliert. Die kompilierten Programme werden auf der GPU ausgeführt.

Illustration des Linux- Grafikstapels: DRM & libDRM, Mesa 3D . Displayserver gehört zum Windowing-System und ist zB für Spiele nicht notwendig.

Implementierungen von Rendering-APIs

Die kostenlosen Implementierungen von Wayland basieren auf der Mesa-Implementierung von EGL . Die spezielle Bibliothek namens libwayland-EGL , die geschrieben wurde, um den Zugriff auf den Framebuffer zu ermöglichen , sollte mit dem Release EGL 1.5 obsolet werden. Auf der GDC 2014 untersuchte AMD eine Strategieänderung hin zur Verwendung von DRM anstelle ihres In-Kernel-Blobs.

Mesa ist als Gehäuseimplementierung von grafischen APIs bekannt . Historisch gesehen ist die Haupt-API, die Mesa implementiert hat, OpenGL , zusammen mit anderen Khronos Group- bezogenen Spezifikationen (wie OpenVG , OpenGL ES oder neuerdings EGL ). Aber Mesa kann andere APIs implementieren, und dies tat es mit Glide (deprecated) und Direct3D 9 seit Juli 2013. Mesa ist auch nicht spezifisch für Unix-ähnliche Betriebssysteme: Unter Windows bietet Mesa beispielsweise eine OpenGL-API über DirectX.

Mesa implementiert eine Übersetzungsschicht zwischen einer Grafik-API wie OpenGL und den Grafikhardwaretreibern im Betriebssystemkernel. Die unterstützte Version der verschiedenen Grafik-APIs hängt vom Treiber ab, da jeder Hardwaretreiber seine eigene Implementierung (und damit Status) hat. Dies gilt insbesondere für die "klassischen" Treiber, während die Gallium3D-Treiber einen gemeinsamen Code verwenden, der dazu neigt, die unterstützten Erweiterungen und Versionen zu homogenisieren.

Mesa unterhält eine Support-Matrix mit dem Status der aktuellen OpenGL-Konformität, die unter mesamatrix .net visualisiert wird . Mesa 10 entspricht OpenGL 3.3 für Intel-, AMD/ATI- und Nvidia-GPU-Hardware. Mesa 11 wurde mit einigen Treibern angekündigt, die OpenGL 4.1-kompatibel sind.

Mesa 12 enthält OpenGL 4.2 und 4.3 und Intel Vulkan 1.0-Unterstützung.

Mesa 13 brachte Intel-Unterstützung für OpenGL 4.4 und 4.5 (alle Features unterstützt für Intel Gen 8+, Radeon GCN, Nvidia (Fermi, Kepler), aber keinen Khronos-Test für 4.5-Label) und experimentelle AMD Vulkan 1.0-Unterstützung durch den Community-Treiber RADV. OpenGL ES 3.2 ist mit Intel Skylake (Gen9) möglich.

Die erste stabile Version von 2017 ist 17.0 (Neujahrszählung). Ready-Funktionen sind zertifiziertes OpenGL 4.5, OpenGL 4.5 für Intel Haswell, OpenGL 4.3 für NVidia Maxwell und Pascal (GM107+). Mit Maxwell 1 (GeForce GTX 750 Ti und mehr mit GM1xx) wurde ein enormer Leistungszuwachs gemessen. Maxwell-2-Karten (GeForce GTX 980 und mehr mit GM2xx) werden ohne NVidia-Informationen untertaktet.

Die Khronos CTS Testsuite für OpenGL 4.4, 4.5 und OpenGL ES 3.0+ ist jetzt (2017-01-24) Open Source und alle Tests für Mesa 13 und 17 sind jetzt kostenlos möglich.

Die zweite stabile Version von 2017, 17.1.0, erschien am 10. Mai 2017 mit einigen interessanten Verbesserungen. OpenGL 4.2+ für Intel Ivy Bridge und OpenGL 3.3+ für Intel Open SWR Rasterizer sind zwei der Highlights.

Beachten Sie, dass Mesa aufgrund der modularisierten Natur von OpenGL tatsächlich Erweiterungen von neueren Versionen von OpenGL unterstützen kann, ohne die vollständige Unterstützung für solche Versionen zu beanspruchen. Im Juli 2016 unterstützte Mesa beispielsweise OpenGL ES 3.1, aber auch alle OpenGL ES 3.2-Erweiterungen mit Ausnahme von fünf sowie eine Reihe von Erweiterungen, die nicht Teil einer OpenGL- oder OpenGL ES-Version sind.

Eine offene Frage für Mesa und Linux ist High Dynamic Range (HDR). Viele Probleme und offene Punkte sind für eine saubere und grundlegende Implementierung in der Pipeline.

3. Version 17.2 ist seit September 2017 mit einigen neuen OpenGL 4.6-Features und Geschwindigkeitsverbesserungen in 3D für Intel und AMD verfügbar. Nur 1,4 % der Tests scheitern für OpenGL 4.5 in Nouveau für Kepler.

4. Version 17.3 ist seit Dezember 2017 fertig. Viele Verbesserungen in vielen Treibern sind vorhanden. OpenGL 4.6 ist fast vollständig verfügbar (Spir-V ist noch nicht fertig). AMD Vulkan Driver RADV ist jetzt im Khronos-Test vollständig konform.

Die erste Version von 2018 ist 18.0 und seit März 2018 nach dem gleichen Schema im Jahr 2017 verfügbar. Die vollständige Unterstützung von OpenGL 4.6 ist noch nicht bereit, aber viele Funktionen und Verbesserungen wurden in RC3 erfolgreich getestet. Ein Highlight ist auch die 10-Bit-Unterstützung für Intel i965 in Colors. Neu ist die Unterstützung für Intel Cannon Lake und AMD Vega mit aktueller Linux-Version. AMD Evergreen Chips (RV800 oder R900) sind nahe an OpenGL 4.5-Unterstützung. Alte AMD R600 oder RV700 Chips können OpenGL 3.3 nur mit einigen Features von OpenGL 4.x unterstützen. Freedreno ist der Treiber für Adreno-Hardware und nahe OpenGL 3.3-Unterstützung.

Die 2. Version von 2018 ist 18.1 und seit Mai verfügbar. Ziel ist Vulkan 1.1.72 im Intel ANV- und AMD RADV-Treiber. OpenGL 4.6 mit spir-V ist ebenfalls Hauptziel. Permanente Arbeit ist möglich Ergänzung von Features und Optimierung von Treibern für ältere Hardware wie AMD R600/Evergreen, Nvidia Tesla und früher, Fermi, Kepler oder Intel Sandybridge, Ivybridge, Haswell oder Broadwell. ARM Architecture hat auch große Verbesserungen in Adreno 3xx/4xx/5xx und Broadwell VC4/VC5 für Raspi mit dem Hauptziel OpenGL ES vorgenommen.

Die dritte Version von 2018 ist 18.2 und im September in der Kalenderversion verfügbar. OpenGL 4.6 mit spir-V und Vulkan 1.1.80 sind in WIP. Der Soft-Treiber für virtuelle Maschinen VIRGL ist bereit für OpenGL 4.3 und OpenGL ES 3.2. RadeonSI ist auch bereit für OpenGL ES 3.2. ASTC-Texturkompressionsunterstützung und Kompatibilitätsmodus-Unterstützung für OpenGL 4.4 (3.1 in 18.1) sind weitere Highlights in RadeonSI für AMD GCN-Karten. Neue Vulkan 1.1 und weitere Funktionen für Intel und AMD sind verfügbar. Weitere Details zu Vulkan in Mesamatrix.

Die 4. Version von 2018 ist 18.3 und wird als stabile Version 18.3.1 im Dezember 2018 veröffentlicht. Viele Features im Detail und die Unterstützung neuerer Hardware sind Hauptbestandteile. Die vollständige Unterstützung von OpenGL 4.6 ist nicht bereit.

Die 1. Version von 2019 ist 19.0 und wurde nun im März veröffentlicht. Die volle Unterstützung von OpenGL 4.6 ist noch nicht fertig, aber viele Verbesserungen auf diesem Weg sind in allen Treibern enthalten.

2. Version von 2019 ist 19.1. Der Übergang von TGSI zu NIR ist hier ein Hauptfeature auf dem Weg zu OpenGL 4.6 mit Spir-V und mehr OpenCL. RadeonSI läuft gut in der Dev-Version mit NIR.

3. Version von 2019 ist 19.2. OpenGL 4.6 ist Beta-bereit für den neuen Intel Iris-Treiber.

4. Version von 2019 ist 19.3. OpenGL 4.6 ist bereit für Intel i965 und optional für den neuen Iris-Treiber.

Die erste Version von 2020 ist 20.0. Vulkan 1.2 ist bereit für AMD RADV und Intel ANV. Intel Iris ist Standard für Intel Broadwell Gen 8+. Der RadeonSI-Treiber hat standardmäßig NIR anstelle von TGSI verwendet.

2. Version von 2020 ist 20.1. Viele Verbesserungen sind in vielen Treibern bereit. Zink ist ein neuer virtueller Treiber für OpenGL over Vulkan.

3. Version von 2020 ist 20.2. OpenGL 3.0 für Zink ist ein neues Feature. LLVMpipe unterstützt OpenGL 4.3+ (4.5+ in 20.3). ARM Panfrost wird meist mit vielen Modulen verbessert. Shared Virtual Memory ist für OpenCL in Nouveau mit Pascal und höher möglich.

4. Version von 2020 ist 20.3. v3d und v3dv sind neue Treiber für OpenGL und Vulkan 1.0 mit Broadcom-Hardware wie Raspberry Pi 4. OpenCL 1.2 wird im Clover-Modul vollständig unterstützt. Zink unterstützt OpenGL 3.3+. Der virtuelle LLVMpipe-Treiber unterstützt jetzt OpenGL 4.5+ mit 4.6 in Aussicht. VALLIUM als Vulkan Tree von LLVMpipe wird zusammengeführt.

In Mesa 21.0 wird d3d12 mit OpenGL 3.0 zu 3.3 zusammengeführt. Microsoft und Collabora entwickeln neue Emulation d3d12 in WSL2 für Windows 10 mit Direct 3D 12. OpenCL 1.2 ist auch in d3d12 Ziel. Eine Beschleunigung von Faktor 2 auf 5 erfolgt im Benchmark SPECviewperf mit verbessertem OpenGL-Code. Viele Features von Mesa 21.0 verbessern die Leistung. Das neue Release 21.0.0 ist seit dem 11. März 2021 öffentlich.

Mesa 21.1 ist das zweite Release des Jahres 2021. Für Zink sind OpenGL 4.6+ und OpenGL ES 3.1+ verfügbar. AMD Driver 600g kann auf NIR umgestellt werden, mit mehr Möglichkeiten für alte Radeeon HD 5000 und 6000 Karten. Qualcomm Turnip erreicht Vulkan 1.1+ und Software-Emulation Lavapipe Vulkan 1.1+. Der Google VirtIO-GPU-Treiber Venus mit Vulkan 1.2+ wird im experimentellen Zustand mit geringer Leistung im Mesa-Hauptbaum zusammengeführt.

Mesa 21.2 ist die dritte Version des Jahres 2021. Google Virtual Vulkan IO Driver Venus wird offiziell mit voller Vulkan 1.2+-Unterstützung (mehr Mesamatrix) eingeführt. ARM Panfrost: OpenGL ES 3.1+ Support ist verfügbar und panVK ist der neue Vulkan-Treiber. Erste Unterstützung für ARM Apple M1 mit dem neuen Treiber Asahi gestartet. 21.2 ist seit dem 4. August 2021 verfügbar.

Ein alter Plan ist es, alte Treiber in einen klassischen Baum mit vielen Vorteilen in Programmierung, Support und Bugfixing für den modernen Gallium-3D-Teil aufzuteilen. Ein Problem hier ist Intel i965 mit Unterstützung von beliebter alter Hardware bis Intel Haswell und davor auch mit Windows 10 Unterstützung. Ein neuer Gallium3D-Treiber Crocus für Intel Gen 4 Graphics von Haswell ist hier in Entwicklung, um hier den Gallium3D-Bereich mit möglicher Aufteilung in der nächsten Zeit des Jahres 2021 zu vervollständigen. Crocus ist optional im 21.2.

Tabelle der Rendering-APIs

Vulkan

Die Khronos Group hat die Vulkan API im März 2015 offiziell angekündigt und am 16. Februar 2016 offiziell Vulkan 1.0 veröffentlicht. Vulkan bricht die Kompatibilität mit OpenGL und gibt sein monolithisches State-Machine-Konzept vollständig auf. Die Entwickler von Gallium3D nannten Vulkan so etwas wie Gallium3D 2.0 – Gallium3D trennt den Code, der die OpenGL State Machine implementiert, von dem hardwarespezifischen Code.

Während Gallium3D TGSI aufnimmt, nimmt Vulkan SPIR-V auf ( Standard Portable Intermediate Representation Version "V" wie in "Vulkan").

Intel veröffentlichte seine Implementierung eines Vulkan-Treibers für seine Hardware am Tag der offiziellen Veröffentlichung der Spezifikation, aber es wurde erst im April gemainlinet und wurde so Teil von Mesa 12.0, das im Juli 2016 veröffentlicht wurde. Während der i965-Treiber laut bereits nicht geschrieben wurde den Gallium3D-Spezifikationen, für den Vulkan-Treiber macht es noch weniger Sinn, ihn auf Gallium3D zu flanschen. Ebenso gibt es keinen technischen Grund, es mit NIR zu flanschen, aber die Mitarbeiter von Intel haben ihren Vulkan-Treiber so implementiert.

Es ist zu erwarten, dass auch AMDs eigener proprietärer Vulkan-Treiber, der im März veröffentlicht wurde und angekündigt wurde, in Zukunft als freie und Open-Source-Software veröffentlicht und in Mesa Mainlined zu werden, ebenfalls auf Gallium3D verzichtet.

RADV ist ein kostenloses Projekt für AMD und seit Version 13 verfügbar. Die Konformität mit Khronos-Test kam in der Version 17.3. Aktuell ist die volle Unterstützung von Vulkan 1.0 und 1.1 seit Mesa 18.1.

Nvidia hat am Starttag ihren proprietären GeForce-Treiber mit Vulkan-Unterstützung veröffentlicht und Imagination Technologies (PowerVR), Qualcomm (Adreno) und ARM (Mali) haben dasselbe getan oder zumindest proprietäre Vulkan-Treiber für Android und andere Betriebssysteme angekündigt. Aber wann und ob zusätzliche kostenlose und Open-Source-Vulkan-Implementierungen für diese GPUs auftauchen, bleibt abzuwarten.

Mesa Software Driver VIRGL startet 2018 Vulkan Development mit GSOC-Projekten zur Unterstützung von virtuellen Maschinen.

Lavapipe ist ein CPU-basierter Software Vulkan-Treiber und der Bruder von LLVMpipe. Mesa Version 21.1 unterstützt Vulkan 1.1+.

Google stellt den Venus Vulkan-Treiber für virtuelle Maschinen in Mesa 21.1 mit voller Unterstützung für Vulkan 1.2+ vor.

Qualcomm Turnip und Broadcom v3dv sind neue Treiber für Qualcomm Adreno und Broadcom Raspberry 4 Hardware. Turnip ist der Vulkan-Bruder von freedreno für OpenGL. V3dv unterstützt Vulkan 1.0+ seit Mesa 20.3. In Version 21.1 unterstützt Turnip Vulkan 1.1+.

Explizites Fechten

Eine Art Speicherbarriere, die einen Puffer vom Rest des Speichers trennt, wird Zaun genannt. Zäune sollen sicherstellen, dass ein Puffer nicht überschrieben wird, bevor die Render- und Anzeigeoperationen darauf abgeschlossen sind. Implizites Fencing wird für die Synchronisierung zwischen Grafiktreibern und der GPU-Hardware verwendet. Der Zaun signalisiert, wenn ein Puffer von einer Komponente nicht mehr verwendet wird, damit er von einer anderen bearbeitet oder wiederverwendet werden kann. In der Vergangenheit hatte der Linux-Kernel einen impliziten Fencing-Mechanismus, bei dem ein Fencing direkt an einen Puffer angehängt wird (vgl. GEM-Handles und FDs), aber Userspace ist sich dessen nicht bewusst. Explizites Fencing macht Zäune dem Userspace zugänglich, wobei der Userspace Fences sowohl vom Direct Rendering Manager (DRM)-Subsystem als auch von der GPU erhält. Explizites Fencing wird von Vulkan gefordert und bietet Vorteile beim Tracing und Debugging.

Linux-Kernel 4.9 fügte der Mainline das Synchronisations-Framework von Android hinzu.

Allgemeine Pufferverwaltung

Generic Buffer Management (GBM) ist eine API, die einen Mechanismus zum Zuweisen von Puffern für das an Mesa gebundene Grafikrendering bereitstellt. GBM soll als native Plattform für EGL auf DRM oder openwfd verwendet werden. Das erstellte Handle kann zum Initialisieren von EGL und zum Erstellen von Renderzielpuffern verwendet werden.

Mesa GBM ist eine Abstraktion der grafiktreiberspezifischen Pufferverwaltungs-APIs (zum Beispiel die verschiedenen libdrm_*-Bibliotheken), die intern durch Aufrufen der Mesa-GPU-Treiber implementiert werden.

Beispielsweise führt der Wayland-Kompositor Weston sein Rendering mit OpenGL ES 2 durch, das er durch Aufrufen von EGL initialisiert. Da der Server auf dem "bare KMS-Treiber " läuft , verwendet er die EGL DRM-Plattform, die man eigentlich als GBM-Plattform bezeichnen könnte, da sie auf der Mesa-GBM-Schnittstelle beruht.

Auf der XDC2014 schlug Nvidia-Mitarbeiter Andy Ritger vor, EGL zu verbessern, um GBM zu ersetzen. Dies wurde von der Community nicht positiv aufgenommen, und Nvidia änderte schließlich ihre Meinung und verfolgte einen anderen Ansatz.

Implementierungen von Videobeschleunigungs-APIs

Es gibt drei Möglichkeiten, die für die Kodierung und Dekodierung von Videostreams erforderlichen Berechnungen durchzuführen:

1. verwenden , um eine Software - Implementierung einer Video - Kompression oder Dekompression - Algorithmus und führen Sie diese Software auf dem (allgemein einen CODEC genannt) C PU
2. Verwenden Sie eine Softwareimplementierung eines Videokomprimierungs- oder -dekomprimierungsalgorithmus (allgemein als CODEC bezeichnet) und führen Sie diese Software auf der G PU (der 3D-Rendering-Engine ) aus.
3. eine vollständige (oder teilweise) Hardwareimplementierung eines Videokomprimierungs- oder -dekomprimierungsalgorithmus verwenden; es ist mittlerweile weit verbreitet, solche ASICs in den Chip der GPU/CPU/APU/SoC zu integrieren und daher reichlich verfügbar; aus Marketinggründen haben Unternehmen Marken für ihre ASICs etabliert, wie PureVideo (Nvidia), Unified Video Decoder (AMD), Video Coding Engine (AMD), Quick Sync Video (Intel), DaVinci (Texas Instruments), CedarX (Allwinner), Kristall-HD (Broadcom); einige ASICs sind für die Lizenzierung als Kern des geistigen Eigentums von Halbleitern verfügbar ; normalerweise implementieren verschiedene Versionen verschiedene Videokompressions- und/oder Videodekompressionsalgorithmen; Unterstützung für solche ASICs gehört normalerweise zum Kernel-Treiber, um die Hardware zu initialisieren und Low-Level-Zeug zu erledigen. Mesa, das im User-Space läuft, beherbergt die Implementierungen mehrerer APIs für Software, z. B. VLC Media Player , GStreamer , HandBrake usw., um bequem auf solche ASICs zuzugreifen:

• Video Acceleration API (VAAPI) – die gebräuchlichste API für Linux, verwendet von AMD und Intel
• Videodecodierungs- und Präsentations-API für Unix (VDPAU) – verwendet von Nvidia
• DirectX-Videobeschleunigung (DXVA) – nur für Microsoft Windows
• OpenMAX IL – von der Khronos Group für die Videokomprimierung entwickelt
• Distributed Codec Engine (DCE) – entwickelt von Texas Instruments
• X-Video Bitstream Acceleration (XvBA) – Erweiterung zu Xv – Nachfolger von VAAPI
• X-Video Motion Compensation (XvMC) – Erweiterung zu Xv – Nachfolger von VAAPI

Beispielsweise unterstützt Nouveau , das als Teil von Mesa entwickelt wurde, aber auch eine Linux-Kernel-Komponente enthält, die als Teil des Linux-Kernels entwickelt wird, die ASICs der Marke PureVideo und bietet Zugriff auf diese über VDPAU und teilweise über XvMC .

Der kostenlose radeon-Treiber unterstützt den Unified Video Decoder und die Video Coding Engine über VDPAU und OpenMAX.

Bitte beachten Sie, dass V4L2 eine Kernel-to-User-Space-Schnittstelle für Video- Bitstreams ist, die von Webcams oder TV-Tunern geliefert werden.

Gerätetreiber

Grafikgerätetreiber werden unter Verwendung von zwei Komponenten implementiert: einem UMD (Benutzermodustreiber) und einem KMD (Kernelmodustreiber). Ab Linux-Kernel 4.2 verwenden AMD Catalyst und Mesa denselben Linux-Kernel-Treiber: amdgpu . Amdgpu bietet von DRM und KMS definierte Schnittstellen.

Die verfügbaren freien und quelloffenen Gerätetreiber für Grafikchipsätze werden von Mesa "verwaltet" (da die vorhandene freie und quelloffene Implementierung von APIs innerhalb von Mesa entwickelt wird). Derzeit gibt es zwei Frameworks zum Schreiben von Grafiktreibern: "klassisch" und Gallium3D. Eine Übersicht über einige (aber nicht alle) der in Mesa verfügbaren Treiber finden Sie unter mesamatrix .net .

Es gibt Gerätetreiber für AMD/ATI R100 bis R800, Intel und Nvidia Karten mit 3D-Beschleunigung. Zuvor gab es Treiber für die IBM/Toshiba/Sony Cell APU der PlayStation 3 , S3 Virge & Savage Chipsätze, VIA Chipsätze, Matrox G200 & G400 und mehr.

Die kostenlosen und Open-Source-Treiber konkurrieren mit proprietären Closed-Source-Treibern. Abhängig von der Verfügbarkeit von Hardware-Dokumentation und Manpower hinkt der kostenlose und Open-Source-Treiber mehr oder weniger hinterher, wenn es um die Unterstützung der 3D-Beschleunigung neuer Hardware geht. Außerdem war die 3D-Rendering-Leistung mit einigen bemerkenswerten Ausnahmen normalerweise deutlich langsamer. Heute gilt dies für Nouveau immer noch für die meisten NVIDIA-GPUs, während bei AMDs Radeon-GPUs der offene Treiber jetzt meistens mit der Leistung des proprietären Treibers übereinstimmt oder diese übertrifft.

Direct-Rendering-Infrastruktur (DRI)

Als sich 3D -Grafikkarten für PCs durchsetzten, begannen Personen, die teilweise von einigen Unternehmen unterstützt wurden, daran zu arbeiten, Mesa mehr Unterstützung für hardwarebeschleunigtes 3D-Rendering zu verleihen. Die Direct Rendering Infrastructure (DRI) war einer dieser Ansätze, um Mesa, OpenGL und andere 3D-Rendering-API-Bibliotheken mit den Gerätetreibern und der Hardware zu verbinden. Nachdem ein grundlegendes Maß an Benutzerfreundlichkeit erreicht war, wurde Mesa offiziell DRI-Unterstützung hinzugefügt. Dadurch wurde die verfügbare Bandbreite an Hardwareunterstützung, die bei Verwendung der Mesa-Bibliothek erreichbar ist, erheblich erweitert.

Mit der Anpassung an DRI übernahm die Mesa-Bibliothek schließlich die Rolle der Front-End-Komponente eines vollständigen OpenGL-Frameworks mit unterschiedlichen Backend-Komponenten, die unterschiedliche 3D-Hardware-Unterstützung bieten konnten, ohne die volle Software-Rendering-Fähigkeit zu verlieren. Das Gesamtsystem verwendet viele verschiedene Softwarekomponenten.

Während das Design ein sorgfältiges Zusammenwirken aller dieser Komponenten erfordert, sind die Schnittstellen zwischen ihnen relativ fest. Da die meisten Komponenten, die mit dem Mesa-Stack interagieren, jedoch Open Source sind, werden experimentelle Arbeiten häufig durch gleichzeitige Änderungen mehrerer Komponenten sowie der Schnittstellen zwischen ihnen durchgeführt. Erweisen sich solche Experimente als erfolgreich, können sie in das nächste Major- oder Minor-Release einfließen. Dies gilt zB für die Aktualisierung der DRI-Spezifikation, die im Zeitraum 2007-2008 entwickelt wurde. Das Ergebnis dieser Experimente, DRI2, arbeitet ohne Sperren und mit verbesserter Unterstützung für den Backpuffer. Dafür wurde ein spezieller Git- Zweig von Mesa erstellt.

DRI3 wird seit 2013 vom Intel-Treiber unterstützt und ist seit 2016 in einigen Linux-Distributionen standardmäßig enthalten, um Vulkan-Unterstützung und mehr zu ermöglichen. Es ist seit Ende 2016 auch Standard auf AMD-Hardware (X.Org Server 1.18.3 und neuer).

Software-Renderer

Mesa enthält auch eine Implementierung von Software-Rendering namens swrast , die es ermöglicht, Shader auf der CPU als Fallback auszuführen , wenn keine Grafikhardwarebeschleuniger vorhanden sind. Der Gallium-Software-Rasterizer ist als softpipe bekannt oder, wenn er mit Unterstützung für LLVM llvmpipe erstellt wurde , die zur Laufzeit CPU-Code generiert. Seit Mesa 10.x wird OpenGL 3.3+ für Softpipe (10.3) und LLVMpipe (10.2) unterstützt. Tatsächlich sind etwa 80% der Features von OpenGL 4.x in Mesa 17.3 implementiert (siehe Mesamatrix).

In Mesa 12.0 steht ein neuer Intel Rasterizer OpenSWR mit hohen Vorteilen in Clustern für große Datensätze zur Verfügung. Es konzentriert sich mehr auf die technische Visualisierung als auf Spiel- oder Kunstbilder und kann nur auf x86-Prozessoren funktionieren. Auf der anderen Seite wird jetzt OpenGL 3.1+ unterstützt. In einigen Beispielen wurden Beschleunigungswerte von 29 bis 51 bezogen auf LLVMPIPE gemessen. OpenGL 3.3+ wird für OpenSWR seit Mesa 17.1 unterstützt.

VirGL ist ein Rasterizer für virtuelle Maschinen, der seit 2015 in Mesa 11.1 mit OpenGL 3.3-Unterstützung implementiert ist und seit Mesa 18 in Mesamatrix gezeigt wird. Im aktuellen neuen Mesa 18.2 unterstützt es mehr als die anderen mit OpenGL 4.3 und OpenGL ES 3.2. Ungefähr 80 % der OpenGL 4.4- und 4.5-Funktionen sind jetzt ebenfalls bereit. Vulkan-Entwicklung beginnt mit GSOC 2018-Projekten.

D3d12 ist ein Projekt von Microsoft für die WSL2-Emulation von OpenGL 3.3+ und OpenCL 1.2+ mit Direct3D 12. D3D12 wird in 21.0 zusammengeführt.

Venus ist ein neuer Vulkan VirtIO GPU-Treiber für GPU in virtuellen Maschinen von Google. Venus wird in 21.1 fusioniert und in 21.2 für die Öffentlichkeit eingeführt.

Mega-Fahrer

Die Idee, mehrere Treiber zu einem einzigen "Mega"-Treiber zu bündeln, wurde von Emma Anholt vorgeschlagen. Es ermöglicht die Verwendung einer einzigen Kopie des gemeinsam genutzten Mesa-Codes von mehreren Treibern (anstatt dass er in jedem Treiber separat vorhanden ist) und bietet aufgrund des Entfernens der internen Bibliotheksschnittstelle eine bessere Leistung als eine separate gemeinsam genutzte Bibliothek. Die State Tracker für VDPAU und XvMC sind zu separaten Bibliotheken geworden.

Shader-DB

shader-db ist eine Sammlung von etwa 20.000 Shadern aus verschiedenen Computerspielen und Benchmarks sowie einigen Skripten, um diese zusammenzustellen und Statistiken zu sammeln. Shader-db soll helfen, eine Optimierung zu validieren.

Es wurde festgestellt, dass eine unerwartete Anzahl von Shadern nicht handgeschrieben, sondern generiert wird. Dies bedeutet, dass diese Shader ursprünglich in HLSL geschrieben und dann von einem Übersetzerprogramm wie zB HLSL2GLSL in GLSL übersetzt wurden . Das Problem ist, dass der generierte Code oft alles andere als optimal ist. Matt Turner sagte, es sei viel einfacher, dies im Übersetzerprogramm zu beheben, als den Compiler von Mesa die Last des Umgangs mit solchen aufgeblähten Shadern tragen zu müssen.

shader-db kann nicht als freie und Open-Source-Software betrachtet werden. Um es legal zu verwenden, muss man eine Lizenz für alle Computerspiele haben, zu denen die Shader gehören.

Softwarearchitektur

Ein Grafiktreiber besteht aus einer Implementierung der OpenGL-Zustandsmaschine und einem Kompilierungsstapel, um die Shader in die Maschinensprache der GPU zu kompilieren . Diese Zusammenstellung, sowie so ziemlich alles andere, wird auf der CPU ausgeführt, dann werden die kompilierten Shader an die GPU gesendet und von dieser ausgeführt. (SDL = Simple DirectMedia Layer ).

Die Zwischendarstellungen (IRs) in Mesa: GLSL IR, Mesa IR, TGSI und LLVM IR . Es fehlen HIR, LIR und NIR.

Mesa IR soll komplett entfernt werden.

Die sogenannten "User-Mode Graphics Device Drivers" (UMD) in Mesa haben nur sehr wenige Gemeinsamkeiten mit dem, was allgemein als Gerätetreiber bezeichnet wird . Es gibt ein paar Unterschiede:

• sie sollen auf zusätzlich existierenden Kernel-Mode-Grafiktreibern arbeiten, die zB als Teil des Linux-Kernels im Quellcode unter /drivers/gpu/drm/Jede UMD kommuniziert mit ihrem Kernel-Mode-Gegenstück mit Hilfe einer speziellen Bibliothek namens libdrm_specific und eine generische namens libdrm . Dieser Abschnitt befasst sich ausschließlich mit dem Benutzermodusteil über libdrm
• es gibt einige Implementierungen des endlichen Automaten, wie sie zB von OpenGL spezifiziert sind; diese Implementierung der OpenGL-Zustandsmaschine kann von mehreren UMDs geteilt werden oder nicht
• sie bestehen zu einem großen Teil aus einer Art Compiler, der zB GLSL aufnimmt und schließlich Maschinencode ausgibt . Parser können von mehreren UMD gemeinsam genutzt werden oder spezifisch sein

Mesas Zwischenvertretungen

Ein Ziel von Mesa ist die Optimierung des Codes, der von der jeweiligen GPU ausgeführt werden soll. Ein anderer ist das Teilen von Code. Anstatt die Software, die dies oder das tut, zu dokumentieren, soll dieser Wikipedia-Artikel stattdessen die Zwischendarstellungen betrachten, die beim Kompilieren und Optimieren verwendet werden. Siehe Abstrakter Syntaxbaum (AST) und Statisches Einzelzuweisungsformular (SSA-Formular).

SPIR-V

SPIR-V ist eine bestimmte Version der Standard Portable Intermediate Representation . Die Idee ist, dass Grafikanwendungen SPIR-V anstelle von GLSL ausgeben. Im Gegensatz zu letzterem ist SPIR-V binär, um Implementierungsunterschiede zwischen GLSL-Compiler-Frontends verschiedener Treiberimplementierungen zu vermeiden, da dies eine Hauptquelle für Anwendungsinkompatibilitäten und Fehler war. Auch die SPIR-V-Binärdatei hat in der Regel auch einige allgemeine Optimierungen durchlaufen. Auch bietet die binäre Darstellung von SPIR-V bis zu einem gewissen Grad einen gewissen Grad an Verschleierung, was für einige Softwareanbieter als eine Form des Schutzes des geistigen Eigentums interessant sein könnte; SPIR-V enthält jedoch zahlreiche Informationen zum Nachdenken, und es gibt Werkzeuge, die SPIR-V wieder in hochwertigen, menschenlesbaren High-Level-Code übersetzen . Eine UMD muss nur Optimierungen anwenden, die spezifisch für die unterstützte Hardware sind.

• SPIR-V-Spezifikation (vorläufig)

GLSL IR

• cgit.freedesktop.org/mesa/mesa/tree/src/compiler/glsl/README
• XDC2014, Matt Turner: Video auf YouTube , Matt Turner - GLSL-Compiler: Wo wir waren und wohin wir gehen
• XDC2015, Matt Turner: Video auf YouTube , www .x .org /wiki /Events /XDC2015 /Program /turner _glsl _compiler .pdf

Mesa IR

NIR

NIR (New Internal Representation) wurde eingeführt, um TGSI-Beschränkungen zu überwinden. NIR wurde in den letzten und aktuellen Releases als Basis der Spir-V-Unterstützung erweitert und ist seit 2016 Hauptentwicklungsgebiet. LLVMpipe, i965, RadeonSI, Nouveau, freedreno, vc4 werden von TGSI in NIR geändert. RADV, Zink und andere neue Treiber starten mit NIR. Alle Treiber mit vollständiger OpenGL 4.6-Unterstützung beziehen sich auf NIR by SPIR-V-Unterstützung. Auch AMD r600 hat eine Gabel mit NIR zur besseren Unterstützung der HD5000- und HD6000-Serien. Diese Option für r600 ist seit Mesa 21.0 Standard.

• Connor Abbott - NIR oder über GLSL IR hinaus in Mesa XDC2014
  • (Mesa-dev) 2014-12-15 Wiedereinführung von NIR, einer neuen IR für Mesa
• cgit.freedesktop.org/mesa/mesa/tree/src/compiler/nir/README
• fosdem.org/2016/schedule/event/i965_nir/attachments/slides/1113/export/events/attachments/i965_nir/slides/1113/nir_vec4_i965_fosdem_2016_rc1.pdf
• NIR in RadeonSI
• Noveau-Update 2018
• Noveau mit NIR in Mesa 19.3

TGSI

Die Tungsten Graphics Shader Infrastructure (TGSI) wurde 2008 von Tungsten Graphics eingeführt. Alle UMDs im Gallium3D-Stil nehmen TGSI auf. NIR ist jetzt Hauptentwicklungsbereich, daher ist TGSI nur für ältere Treiber wie die r300g-Standardinfrastruktur gedacht und wird in einigen Jahren veraltet sein.

LLVM IR

Die UMDs radeonsiund llvmpipegeben keinen Maschinencode aus, sondern LLVM IR. Von nun an führt LLVM Optimierungen und die Kompilierung in Maschinencode durch. Dies bedeutet, dass auch eine bestimmte Mindestversion von LLVM installiert sein muss.

RADV ACO IR

RADV ACO verwendet eigene IR, die nahe an NIR liegen, um Endbinärcode für Vulkan SPIR-V Shader auf Radeon GPUs (GCN 1+, aka GFX6+) GPUs zu optimieren und zu generieren. Ab Version 20.1.0 wird der ACO nur noch in RADV (Vulkan-Treiber) und noch nicht in RadeonSI verwendet.

GLSL-Compiler von Mesa

Der GLSL-Compiler von Mesa generiert seine eigene IR. Da jeder Treiber sehr unterschiedliche Anforderungen an einen LIR stellt, unterscheidet er zwischen HIR (High-Level-IR) und LIR (Low-Level-IR).

Gallium3D

Gallium3D ist eine Reihe von Schnittstellen und eine Sammlung unterstützender Bibliotheken, die die Programmierung von Gerätetreibern für 3D- Grafikchipsätze für mehrere Betriebssysteme, Rendering- oder Videobeschleunigungs-APIs erleichtern sollen .

Eine Feature-Matrix wird unter mesamatrix .net bereitgestellt , und die Bemühungen, freie und Open-Source-Gerätetreiber für Grafikchips zu schreiben, werden separat in der Wikipedia dokumentiert: Free and Open-Source-Grafikgerätetreiber .

Die Entwicklung von Gallium3D begann 2008 bei Tungsten Graphics, und die Implementierung ist als kostenlose Open-Source-Software als Teil von Mesa 3D verfügbar, das von freedesktop.org gehostet wird . Das Hauptziel besteht darin, die Treiberentwicklung zu vereinfachen, ansonsten duplizierten Code mehrerer verschiedener Treiber an einem einzigen Punkt zu bündeln und moderne Hardwarearchitekturen zu unterstützen. Dies geschieht durch eine bessere Arbeitsteilung, beispielsweise indem die Speicherverwaltung dem Kernel- DRI- Treiber überlassen wird .

Gallium3D ist seit 2009 ein Teil von Mesa und wird derzeit von den kostenlosen und Open-Source -Grafiktreibern für Nvidia ( Nouveau- Projekt), für AMDs R300 – R900 , Intels ' Iris' -Treiber für Generation 8+ iGPUs und für andere kostenlose und Open-Source-GPU-Gerätetreiber .

Softwarearchitektur

Gallium3D vereinfacht die Programmierung von Gerätetreibern, indem es den Grafikgerätetreiber in drei Teile aufteilt. Dies wird durch die Einführung von zwei Schnittstellen erreicht : Gallium3D State Tracker Interface und Gallium3D WinSys Interface . Die drei Komponenten heißen:

Gallium3D State Tracker

• Jede grafische API, über die ein Gerätetreiber angesprochen wird, hat einen eigenen State Tracker, zB gibt es einen Gallium3D State Tracker für OpenGL und einen anderen für Direct3D oder GLX . Jeder State Tracker enthält eine Implementierung der Gallium3D State Tracker Schnittstelle und ist einzigartig, das heißt, sie wird von allen existierenden Gallium3D Gerätetreibern gemeinsam genutzt.

Gallium3D-Hardware-Gerätetreiber

• Dies ist der eigentliche Code, der für den zugrunde liegenden 3D-Grafikbeschleuniger spezifisch ist, jedoch nur soweit dies die Gallium3D-WinSys-Schnittstelle zulässt. Für jeden verfügbaren Grafikchip gibt es einen einzigartigen Gallium3D-Hardware-Gerätetreiber, und jeder implementiert die Gallium3D-State-Tracker-Schnittstelle sowie die Gallium3D-WinSys-Schnittstelle. Der Gallium3D-Hardware-Gerätetreiber versteht nur TGSI (Tungsten Graphics Shader Infrastructure), eine Zwischensprache zur Beschreibung von Shadern. Dieser Code übersetzte Shader, die von GLSL in TGSI übersetzt wurden, weiter in einen von der GPU implementierten Befehlssatz .

Gallium3D WinSys

• Dies ist spezifisch für den zugrunde liegenden Kernel des Betriebssystems und jeder implementiert die Gallium3D WinSys-Schnittstelle, um mit allen verfügbaren Gallium3D-Hardware-Gerätetreibern zu kommunizieren.

VC4 und freedreno können beide NIR direkt konsumieren (und für Shader, die glsl_to_nir nicht verwenden, auf tgsi_to_nir zurückgreifen).

Abbildung des Linux- Grafikstapels

Mesa / DRI und Gallium3D haben unterschiedliche Treibermodelle. Beide teilen sich viel kostenlosen und Open-Source- Code

Eine mögliche Beispielmatrix bei der Implementierung des Gallium3D-Treibermodells. Durch die Einführung des Gallium3D Tracker Interface und des Gallium3D WinSys Interface werden nur noch 18 statt 36 Module benötigt. Jedes WinSys-Modul kann mit jedem Gallium3D-Gerätetreibermodul und mit jedem State-Tracker-Modul arbeiten.

Unterschiede zu klassischen Grafiktreibern

Gallium3D bietet eine einheitliche API , die Standard-Hardwarefunktionen wie Shader- Einheiten moderner Hardware bereitstellt . Daher benötigen 3D-APIs wie OpenGL 1.x/2.x, OpenGL 3.x, OpenVG , GPGPU- Infrastruktur oder sogar Direct3D (wie in der Wine- Kompatibilitätsschicht zu finden) nur ein einziges Back-End, einen sogenannten State-Tracker. auf die Gallium3D-API abzielen. Im Gegensatz dazu erfordern DRI-Gerätetreiber im klassischen Stil für jede Hardwareplattform ein anderes Back-End, und mehrere andere APIs müssen auf Kosten der Codeduplizierung in OpenGL übersetzt werden. Alle Gerätetreiber von Herstellern sind aufgrund ihrer proprietären und Closed-Source-Natur so geschrieben, was bedeutet, dass zB der AMD Catalyst sowohl OpenGL als auch Direct3D implementiert und die Herstellertreiber für die GeForce ihre Implementierungen haben.

Unter Gallium3D verwalten die Kerneltreiber des Direct Rendering Manager (DRM) den Speicher und die Treiber des Direct Rendering Interface (DRI2) sind stärker auf die GPU-Verarbeitung ausgerichtet. Während der Übergangszeit vom Userspace-Modus zum Kernelspace-Modus unterstützten einige der Mesa-3D-Treiber, wie der Radeon-Treiber oder die Treiber von Intel, sowohl DRI1 als auch DRI2 und verwendeten DRI2, falls auf dem System verfügbar. Gallium3D benötigt außerdem eine Shader-Unterstützung, die auf älteren Karten wie zB ATi r100-r200 nicht verfügbar ist, sodass Benutzer dieser Karten weiterhin Mesa 3D mit DRI2 für ihre 3D-Nutzung verwenden müssen.

Tungsten Graphics Shader Infrastruktur

Tungsten Graphics Shader Infrastructure ( TGSI ) ist eine Intermediate-Darstellung wie die LLVM Intermediate Representation oder die neue Standard Portable Intermediate Representation (SPIR), die von der Vulkan API und OpenCL 2.1 verwendet wird. In OpenGL Shading Language geschriebene Shader sollen in TGSI übersetzt/kompiliert werden, dann werden Optimierungen vorgenommen und dann werden die TGSI-Shader in Shader für den Befehlssatz der verwendeten GPU kompiliert .

NIR ist die neue Layer-Darstellung in Mesa mit voller SPIR-V-Unterstützung und seit 2019 Hauptentwicklungsbereich aller neueren Treiber mit OpenGL 4.6-Unterstützung.

LLVM-Nutzung

GlassyMesa ist ein LLVM-basierter Compiler-Stack für in GLSL geschriebene Shader . Für SSA siehe den Artikel Statisches Einzelzuweisungsformular .

Darüber hinaus gibt es unter Verwendung der modularen Struktur von Gallium3D Bestrebungen, die LLVM- Compiler-Suite zu verwenden und ein Modul zu erstellen, um Shader- Code im laufenden Betrieb zu optimieren .

Die Bibliothek stellt jedes Shader-Programm unter Verwendung einer erweiterbaren binären Zwischendarstellung namens Tungsten Graphics Shader Infrastructure (TGSI) dar, die LLVM dann in für die Zielhardware optimierte GLSL- Shader übersetzt .

Annahme

Mehrere freie und Open-Source - Grafikgerätetreiber , die gewesen sind, oder geschrieben werden Informationen auf der Grundlage gewonnen durch Reinraum Reverse Engineering , das Treibermodell von Gallium3D, zB erlassen nouveau und andere ( siehe Freie und Open-Source - Grafikgerät Treiber für eine vollständige Liste ). Der Hauptgrund kann sein, dass das Gallium3D-Treibermodell die Menge an Code verringert, die geschrieben werden muss. Da dieser Code unter einer freien Softwarelizenz lizenziert ist, kann er natürlich jederzeit von jedermann umgeschrieben werden, um das DRI- oder ein anderes Treibermodell zu implementieren.

Geschichte

Die ursprünglichen Autoren von Gallium3D waren Keith Whitwell und Brian Paul von Tungsten Graphics (2008 von VMware übernommen).

Meilensteine

Im Herbst 2011 gab es mindestens 10 bekannte, ausgereifte und funktionierende Gallium3D-Treiber. Open-Source-Treiber für Nvidia-Grafikkarten namens Nouveau- Team entwickelt seine Treiber mit dem Gallium3D-Framework.

2008-07-13: Die Nouveau-Entwicklung erfolgt ausschließlich für das Gallium-Framework. Der alte DRI-Treiber wurde aus dem Master-Zweig des Mesa-Repositorys auf Freedesktop.org entfernt.

11.02.2009: Der Gallium-0.2-Zweig wurde in den Mainline-Master-Zweig von Mesa eingegliedert. Die Entwicklung erfolgt in Mesa Mainline.

2009-02-25: Gallium3D kann sowohl auf Linux als auch auf FreeBSD-Kernels laufen.

01.05.2009: Zack Rusin von Tungsten Graphics hat Mesa 3D um den OpenVG State Tracker erweitert, der es ermöglicht Scalable Vector Graphics durch jeden Gallium3D-basierten Treiber hardwarebeschleunigt zu werden.

17.07.2009: Mesa3D 7.5 wird veröffentlicht, die erste Version mit Gallium3D.

10.09.2010: Erste Unterstützung für die Evergreen-GPUs wurde dem r600g-Treiber hinzugefügt.

21.09.2010: Es gibt zwei Gallium3D-Treiber für ATI-Hardware, die als r300g und r600g für R300-R500 bzw. R600-Evergreen GPUs bekannt sind.

2010-09-21: Der Code wurde stark festgeschrieben , um Direct3D 10 und 11 zu unterstützen. Mit der Zeit könnte dies die Möglichkeit bieten, neuere Direct3D-Implementierungen auf Linux-Systemen zu verwenden.

30.11.2011: Intel 965g und Cell Gallium Treiber wurden als nicht gewartet und defekt aus dem Master-Zweig von Mesa entfernt.

2013-11-30: Mesa 10 mit OpenGL 3.2, 3.3 und OpenCL 1.0+

18.11.2014: Der Code wurde stark festgeschrieben , um Direct3D 9 zu unterstützen.

15.09.2015: Mesa 11 mit OpenGL 4.0, 4.1 und OpenCL 1.2 (unvollständig)

15.12.2015: Mesa 11.1 Treiber VIRGL für virtuelle Maschinen mit OpenGL 3.3

08.07.2016: Mesa 12 mit OpenGL 4.2, 4.3 und Vulkan 1.0 (Intel ANV und AMD RADV)

01.11.2016: Mesa 13 mit OpenGL 4.4 und OpenGL ES 3.2

13.02.2017: Mesa 17.0 mit OpenGL 4.5 und freedreno-Treiber mit OpenGL 3.0 und 3.1

10.05.2017: Mesa 17.1 OpenGL 4.2+ für Intel Ivy Bridge (mehr als Intel Treiber für Windows, OpenGL 3.3+ für Intel Open SWR Rasterizer (wichtig für Cluster Computer für große Simulationen)

08.12.2017: Mesa 17.3 AMD Vulkan Driver RADV voll kompatibel im Khronos Test von Vulkan 1.0

18.05.2018: Mesa 18.1 mit Vulkan 1.1 (Intel ANV und AMD RADV)

07.09.2018: Mesa 18.2 mit OpenGL 4.3 für Soft Driver VIRGL (wichtig für virtuelle Maschinen in Cloud Cluster Computer), OpenGL ES 3.1 für Freedreno mit Adreno A5xx

11.06.2019: Mesa 19.1 mit Intels ' iris'-Grafiktreiber der nächsten Generation für iGPUs der Generation 8+ veröffentlicht

11.12.2019: Mesa 19.3 veröffentlicht OpenGL 4.6 mit Intel i965 mit Gen 7+ und optionaler Iris Gen 8+

18.03.2020: Mesa 20.0 veröffentlicht OpenGL 4.6 mit AMD GCN und Vulkan 1.2 für Intel

27.05.2020: Mesa 20.1 veröffentlicht NIR-Vektorisierungsunterstützung und Shared Virtual Memory-Unterstützung für OpenCL in Clover

30.11.2020: Mesa 20.3 volle Unterstützung von OpenCL 1.2 in Clover

2021-03-11: Mesa 21.0 Erstunterstützung von „D3D12“: Direct 3D 12 für WSL2 in Windows 10 mit OpenGL 3.3+, ARM Freedreno: OpenGL 3.3+

05.05.2021: Mesa 21.1 Erstunterstützung des Google VirtIO GPU-Treibers „Venus“ mit Vulkan 1.2+; Zink: OpenGL 4.6+, OpenGL ES 3.1+; Qualcomm Rübe, Lavapipe: Vulkan 1.1+

04.08.2021: Mesa 21.2 Erstunterstützung des neuen Intel Crocus OpenGL 4.6 Treibers basierend auf gallium3D zu Intel Sandy Bridge zu Haswell für alten i965, Vulkan Treiber panVK für ARM Panfrost

Leistung

• Leistungsvergleich von kostenlosen und Open-Source-Grafikgerätetreibern

Geschichte

Der Projektinitiator Brian Paul war ein Hobbygrafiker. Er dachte, es würde Spaß machen, eine einfache 3D-Grafikbibliothek mit der OpenGL-API zu implementieren, die er dann anstelle von VOGL (sehr gewöhnliche GL-ähnliche Bibliothek) verwenden könnte. Ab 1993 verbrachte er 18 Monate in Teilzeit mit der Entwicklung, bevor er die Software im Februar 1995 im Internet veröffentlichte. Die Software wurde gut angenommen und die Leute begannen, an ihrer Entwicklung mitzuwirken. Mesa begann damit, alle 3D-Computergrafiken auf der CPU zu rendern . Trotzdem wurde die interne Architektur von Mesa so konzipiert, dass sie für die Anbindung an Grafikprozessor- beschleunigtes 3D-Rendering offen ist . In dieser ersten Phase wurde das Rendering indirekt im Display-Server durchgeführt , wodurch ein gewisser Overhead und eine spürbare Geschwindigkeit hinter dem theoretischen Maximum zurückblieben. Das Diamond Monster 3D mit dem Voodoo Graphics- Chipsatz war eines der ersten von Mesa unterstützten 3D-Hardwaregeräte.

Die erste echte Unterstützung für Grafikhardware wurde 1997 zu Mesa hinzugefügt, basierend auf der Glide-API für die damals neuen 3dfx Voodoo I/II -Grafikkarten und deren Nachfolger. Ein großes Problem bei der Verwendung von Glide als Beschleunigungsschicht war die Angewohnheit von Glide, im Vollbildmodus zu laufen, was nur für Computerspiele geeignet war. Außerdem hat Glide die Sperre des Bildschirmspeichers aufgehoben, und somit wurde der Anzeigeserver daran gehindert, andere GUI-Aufgaben auszuführen.

Siehe auch

• Kostenloser und Open-Source-Grafikgerätetreiber

Verweise

Externe Links

• Offizielle Website
• Edge, Jake (Oktober 2013). "Die Geschichte von Mesa" .

Externe Links für Gallium3D

• freedesktop.org - Gallium3D , ein Artikel zum aktuellen Stand von Gallium3D
• Fonseca, José (April 2008), Einführung in Gallium3D
• Rusin, Zack (21. September 2007), Gallium3D
• Corbet, Jonathan (November 2007), Speicherverwaltung für Grafikprozessoren
• Generic GPU-Accelerated Video Decoding , Google Summer of Code 2008-Projekt mit Gallium, archiviert vom Original am 31. Juli 2008
• Rusin, Zack (2008), Gallium3D: Graphics Done Right (PDF) (Präsentation), Akademie
• Rusin, Zack (2008), Gallium3D: Graphics Done Right (Präsentation), Akademy , archiviert vom Original (Video) am 1. Januar 2011
• Update zu Gallium3D-Ports zu AROS und Haiku (PDF) , FOSDEM 2010, 7. Februar 2010