Downloads
Sponsoring
Bekannte Probleme
Unterschiede zwischen MSVC- und MinGW-Paketen
Inhalt des Mingw- und MSVC-Pakets
Gemeinsame gemeinsam genutzte Bibliotheken von OpenGL und OpenGL ES
Gemeinsame Abhängigkeit von Microsoft CLonD3D12, GLonD3D12, Dozen Vulkan-Treiber und D3D12 VA-API
Desktop-OpenGL-Treiber
OpenGL-Offscreen-Rendering-Treiber
OpenGL ES-Treiber und EGL-Bibliothek
Vulkan-Treiber
OpenCL-Treiber, Compiler und Backends
Direct3D-Treiber, Bibliotheken und Tools
VA-API-Treiber
Testbibliothek und Tools
Entwicklungspakete
Pakete debuggen
Bauen Sie Mesa3D selbst
Installation und Nutzung
Nutzungshinweise
Deinstallieren Sie Mesa3D
Kompatibilität mit Legacy-Software
Überschreibung der OpenGL-Kontextkonfiguration
So legen Sie Umgebungsvariablen fest
Mesa 24.2.6-Builds mit Visual Studio und MSYS2 Mingw-w64 sind jetzt im Abschnitt „Releases“ verfügbar.
Das mesa-dist-win-Projekt erhielt ein Sponsoring, das bis zum 1. November 2024 verlängert wurde. Das Sponsoring besteht aus einem kostenlosen VPS auf einem französischen Knoten zur Verwendung als Build-Maschine mit 12 GB RAM, 6 Threads AMD EPYC 7763 und 150 GB NVMe SSD von Petrosky. ein virtuelles privates Server-Hosting-Unternehmen dank @Directox01.
Dies ist eine Liste aller häufig auftretenden Probleme mit bekannten Lösungen oder Problemumgehungen. Eine bestimmte Version ist nur von einer Teilmenge davon betroffen.
libgallium_wgl.dll fehlt Fehler mit Mesa3D OpenGL ES und Desktop-OpenGL-Treibern
Dies tritt bei vorhandenen anwendungsbezogenen Bereitstellungen auf, die mit 21.2.x oder älter erstellt wurden, wenn auf 21.3.0 oder neuer aktualisiert wird. Wiederholen Sie einfach die Bereitstellung pro App, um das Problem zu beheben. Die Trennung des Gallium-Megadrivers von opengl32.dll war eine sehr invasive Änderung, gegen die bestehende App-Bereitstellungen keine Chance hatten. Wenn Sie sich nicht erinnern, ob ein betroffenes Programm 32-Bit oder 64-Bit ist, klicken Sie mit der rechten Maustaste auf die Verknüpfung opengl32.dll in dem Ordner, in dem sich die ausführbare Programmdatei befindet, und wählen Sie den Speicherort der geöffneten Datei aus. Wenn der Standort auf x64 endet, handelt es sich um 64-Bit, andernfalls um 32-Bit.
libEGL.dll fehlt Fehler mit Mesa3D OpenGL ES
Dies tritt bei vorhandenen anwendungsbezogenen Bereitstellungen auf, die mit 21.2.x oder älter erstellt wurden, wenn auf 21.3.0 oder neuer aktualisiert wird. Wiederholen Sie einfach die Bereitstellung pro App, um das Problem zu beheben. Die EGL-Unterstützung war eine sehr invasive Änderung, gegen die bestehende Pro-App-Bereitstellungen keine Chance hatten. Wenn Sie sich nicht erinnern, ob ein betroffenes Programm 32-Bit oder 64-Bit ist, klicken Sie mit der rechten Maustaste auf die Verknüpfung opengl32.dll in dem Ordner, in dem sich die ausführbare Programmdatei befindet, und wählen Sie den Speicherort der geöffneten Datei aus. Wenn der Standort auf x64 endet, handelt es sich um 64-Bit, andernfalls um 32-Bit.
libvulkan-1.dll fehlt Fehler mit Mesa3D opengl32.dll aus dem MinGW-Release-Paket
Betroffen sind nur Versionen vor 22.2.0, für die der Zink-Treiber mit der Paketgruppe MSYS2 MinGW-W64 vulkan-devel erstellt wurde. Führen Sie fix-libvulkan-1.dll-missing-error.cmd aus dem MinGW-Release-Paket aus, um das Problem zu beheben. Dieses Tool unterstützt die unbeaufsichtigte Ausführung über auto Befehlszeilenoption. Dieses Tool ist nur bei Bedarf im MinGW-Release-Paket enthalten, andernfalls fehlt es absichtlich. Die Entscheidung, dieses Vulkan-SDK anstelle von LunarG zu verwenden, wird auf der Grundlage dessen getroffen, dass es über neuere Loader und Header verfügt.
64-Bit-Binärdateien in MSVC- und MinGW-Paketen erfordern eine CPU mit AVX, obwohl dies nicht der Fall sein sollte
Dies ist ab Mesa 22.0 oder neuer kein Problem mehr. Dieses Problem wird durch 64-Bit-Binärdateien verursacht, die den SWR-Treiber enthalten, wodurch die AVX-Nutzung in den allgemeinen Code gelangt. Dies ist ein Upstream-Fehler, der hier, hier und hier gemeldet wurde.
Mesa opengl32.dll aus dem MinGW-Paket hängt seit 21.0.0 von der Vulkan-Laufzeit ab
Dies wurde in 22.2.0 behoben, indem diese Anforderung enthalten wurde, um die explizite Verwendung des Treibers zu verhindern. Dies ist eine Upstream-Regression, die eingeführt wurde, als der Zink-Treiber gepatcht wurde, um Windows zu unterstützen.
Bei Verwendung von Mesa opengl32.dll seit 21.0.0 können sich Programme so verhalten, als gäbe es keine OpenGL-Unterstützung
Hierbei handelt es sich nicht um einen Defekt, sondern um eine Verhaltensänderung von Mesa, wenn Umgebungsvariablen falsch konfiguriert sind. Dies geschieht normalerweise, wenn ein Mesa-Treiber ausgewählt wird, der im verwendeten Release-Paket nicht vorhanden ist, oder wenn die Initialisierung fehlschlägt, weil das Hostsystem die Hardwareanforderungen nicht erfüllt oder keine Abhängigkeiten vorhanden sind. Das Lesen der Unterschiede zwischen MSVC- und MinGW-Paketen und den Inhalten von Mingw- und MSVC-Paketen sollte bei der Fehlerbehebung hilfreich sein.
Wichtige Hinweise zu Fehlern im Zusammenhang mit fehlender libglapi.dll
Sie können bei Programmen auftreten, die einen Mesa3D-Desktop-OpenGL-Treiber über ein App-Bereitstellungstool verwenden. Die systemweite Bereitstellung ist davon nicht betroffen. Sie können davon betroffen sein, wenn die Bereitstellung pro App vor der Einführung der Shared-Glapi-Unterstützung erfolgt ist. Shared Glapi ist seit 20.0.2 durchgehend sowohl in MSVC- als auch in MinGW-Paketen verfügbar.
Um diese Fehler unabhängig von der Ursache zu beheben, müssen Sie die Bereitstellung erneut durchführen. Wenn Sie sich nicht erinnern, ob ein betroffenes Programm 32-Bit oder 64-Bit ist, klicken Sie mit der rechten Maustaste auf die Verknüpfung opengl32.dll in dem Ordner, in dem sich die ausführbare Programmdatei befindet, und wählen Sie den Speicherort der geöffneten Datei aus. Wenn der Standort auf x64 endet, handelt es sich um 64-Bit, andernfalls um 32-Bit.
Das gleiche Problem mit der gleichen Lösung gilt für Osmesa, wenn Sie ein Upgrade von 17.3.5.501-1 oder älter durchführen.
Das MinGW-Paket erfordert eine CPU mit SSSE3 mit dem Vorteil einer Leistungssteigerung von 3–5 % mit Software-Rendering-Treibern;
d3d10sw, eingeführt in 21.2.0, ist nur im MSVC-Paket verfügbar.
Wenn Sie von Mingw auf MSVC-Binärdateien migrieren müssen, müssen Sie lediglich den Mesa-Binärordner aus dem Mingw-Paket durch das MSVC-Gegenstück ersetzen.
Die folgenden Mesa3D-Treiber und Build-Artefakte werden in jeder Version ausgeliefert:
GLAPI-Gemeinschaftsbibliothek. Dateiname: libglapi.dll . Seine Anwesenheit ist erforderlich, wenn sowohl OpenGL- als auch OpenGL ES-Unterstützung bereitgestellt wird. Der Off-Screen-Renderer von Mesa3D und alle Mesa3D OpenGL- und OpenGL ES-Treiber sind davon abhängig, sofern vorhanden. Seit 20.0.2 ist es sowohl in den Paketen MSVC als auch MSYS2 Mingw-w64 verfügbar.
Gallium OpenGL-Megatreiber. Dateiname: libgallium_wgl.dll . Wenn vorhanden, enthält es alle Mesa3D-Desktop-OpenGL-Treiber anstelle von opengl32.dll . Es debütierte in 21.3.0. Die Mesa3D EGL-Bibliothek und OpenGL ES-Treiber sind davon abhängig, sofern vorhanden.
Mesa3D WGL-Laufzeit. Dateiname: opengl32.dll . Dieser enthielt früher alle Mesa3D-Desktop-OpenGL-Treiber und OpenGL ES war davon abhängig, aber seit 21.3.0 war er nur noch ein Lader für den Gallium OpenGL-Megatreiber, sodass nur Programme, die Mesa3D-Desktop-OpenGL-Treiber über die Bereitstellung pro Anwendung verwenden, davon abhängig waren Jetzt.
DirectX IL zur Weiterverbreitung. Dateiname: dxil.dll . Diese binäre Redistributable wird im Windows SDK und im DirectX Shader Compiler bereitgestellt und während des Veröffentlichungsprozesses gepackt. Bereitstellungstools installieren es nach Bedarf.
llvmpipe. llvmpipe ist ein Desktop-OpenGL-Software-Renderer, der als Ersatz gedacht ist, wenn eine Hardwarebeschleunigung nicht möglich ist. Es kann nur sehr leichte Spiele mit guter Leistung bewältigen. Dies ist der Standard-Mesa3D-Desktop-OpenGL-Treiber, wenn GLonD3D12 entweder nicht verfügbar ist oder nicht geladen werden kann. Es ist sowohl für x86 als auch für x64 als Teil des Mesa3D Desktop OpenGL-Pakets opengl32.dll oder libgallium_wgl.dll verfügbar, sofern letzteres verfügbar ist. Wenn es sich nicht um den Standardtreiber handelt, wählen Sie ihn aus, indem Sie die Umgebungsvariable GALLIUM_DRIVER=llvmpipe festlegen.
Softpipe ist eine Referenzimplementierung eines Desktop-OpenGL-Software-Renderers ohne Fokus auf Spieleleistung. Es ist sowohl für x86 als auch für x64 als Teil des Mesa3D Desktop OpenGL-Pakets opengl32.dll oder libgallium_wgl.dll verfügbar, sofern letzteres verfügbar ist. Wählen Sie es aus, indem Sie die Umgebungsvariable GALLIUM_DRIVER=softpipe festlegen.
GLonD3D12. Es ist sowohl für x86 als auch x64 im MSVC-Paket und seit 22.2.0 im MinGW-Paket sowie als Teil des Mesa3D Desktop OpenGL-Pakets opengl32.dll oder libgallium_wgl.dll verfügbar, sofern letzteres verfügbar ist, und vor 22.3.0 als eigenständige openglon12.dll sowie. Neben der offiziellen Anforderung von Windows 10 v10.0.19041.488 oder neuer ist für die Neuverteilung auch DirectX IL erforderlich – dxil.dll zum Laden, das über Bereitstellungstools installiert werden kann. Sofern verfügbar und wenn er geladen werden kann, ist dies der standardmäßige Mesa3D-Desktop-OpenGL-Treiber auf D3D12-GPU-beschleunigten Systemen. Dieser in 21.0.0 eingeführte Treiber fungiert als Wrapper, der D3D12-API-Aufrufe zurückgibt. Aufgrund dieser Beschaffenheit kann die GPU-Beschleunigung genutzt werden. Wenn es nicht standardmäßig ausgewählt ist, können Sie es mit dem in Windows integrierten Direct3D WARP-Software-Renderer testen, indem Sie die Umgebungsvariablen GALLIUM_DRIVER=d3d12 und LIBGL_ALWAYS_SOFTWARE=1 festlegen. Für die eigenständige Kopie muss GALLIUM_DRIVER=d3d12 nicht festgelegt werden und sie kann nur über das systemweite Bereitstellungstool installiert werden. Die eigenständigen Pakete GLonD3D12 und Mesa3D Desktop OpenGL ersetzen sich gegenseitig, wenn Sie ein systemweites Bereitstellungstool verwenden, Sie können dies jedoch jederzeit rückgängig machen.
Zink. Dieser Treiber wurde im MinGW-Paket in 21.0.0 und im MSVC-Paket in 21.2.0 eingeführt und ist sowohl für x86 als auch für x64 als Teil des Mesa3D Desktop OpenGL-Pakets opengl32.dll oder libgallium_wgl.dll verfügbar, sofern letzteres verfügbar ist. Ähnlich wie GLonD3D12 fungiert es als Wrapper, der Vulkan-API-Aufrufe zurückgibt. Aus diesem Grund nutzt es standardmäßig die GPU-Beschleunigung, unterstützt aber auch Software-Rendering. Wählen Sie es über die Umgebungsvariable GALLIUM_DRIVER=zink aus. Beachten Sie jedoch, dass zur Initialisierung mindestens ein Vulkan-Gerät und ein Vulkan-Loader/Laufzeit erforderlich sind. Bis 22.1.0 ignorierte Zink standardmäßig Vulkan-CPU-Geräte. Heutzutage wird ein Prioritätssystem verwendet, das automatisch ein Vulkan-CPU-Gerät auswählt, wenn kein Vulkan-Typ-Gerät mit höherer Priorität vorhanden ist. Sie können Zink nur mit Vulkan-CPU-Geräten testen, indem Sie LIBGL_ALWAYS_SOFTWARE=1 (Mesa 22.1.0 und neuer) oder ZINK_USE_LAVAPIPE=true (in Mesa 22.1.0 veraltet) festlegen.
swr. Dieser Treiber ist in Mesa 22.0 und neuer nicht mehr verfügbar. Dateinamen: swrAVX.dll , swrAVX2.dll , swrSKX.dll , swrKNL.dll . Auch wenn es sich außerhalb des Mesa3D Desktop OpenGL-Bundles opengl32.dll oder libgallium_wgl.dll befindet, sofern letzteres verfügbar ist, hängt es dennoch davon ab. Dieser von Intel entwickelte alternative Desktop-OpenGL-Software-Rendering-Treiber ist für Visualisierungssoftware optimiert. Es ist im MSVC-Paket und seit 20.1.7 auch im MinGW-Paket verfügbar. Es unterstützt nur x64, x86 wird offiziell nicht unterstützt. Derzeit gibt es 4 DLLs, von denen nur eine geladen wird, je nachdem, was die Benutzer-CPU tun kann. Sie können zu swr wechseln, indem Sie den Wert der Umgebungsvariablen GALLIUM_DRIVER auf swr setzen.
Osmesa. Dateiname: osmesa.dll . Verfügbar für x86 und x64. Dieser Treiber wird in besonderen Fällen von Software verwendet, die Mesa-Code zum Rendern ohne Abhängigkeit vom Fenstersystem oder Betriebssystem verwenden soll. Seit 21.0.0 blieb nur noch Osmesa-Gallium übrig. Es unterstützt OpenGL 3.x und neuer. Seit 20.0.2 ist die Osmesa-Integration mit eigenständigen GLLES-Treibern sowohl in MSVC- als auch in MSYS2-Mingw-w64-Paketen verfügbar, die dabei libglapi.dll erfordern.
EGL-Bibliothek. Dateiname: libEGL.dll . Mesa3D EGL-Bibliothek, die von OpenGL ES-Treibern verwendet wird. Dies wurde in 21.3.0 eingeführt und ist für 32-Bit- und 64-Bit-Anwendungen sowohl in MSVC- als auch in MSYS2-Paketen verfügbar. Es hängt vom Desktop-OpenGL-Bundle opengl32.dll oder libgallium_wgl.dll ab, ob letzteres verfügbar ist.
Eigenständige OpenGL ES-Treiber. Dateinamen: libGLESv1_CM.dll und libGLESv2.dll . Standalone-Treiber für OpenGL ES 1.x, 2.x und 3.x sind für 32-Bit- und 64-Bit-Anwendungen verfügbar. Seit 20.0.2 sind sie sowohl in den Paketen MSVC als auch MSYS2 Mingw-w64 verfügbar. Sie sind abhängig von der Mesa3D EGL-Bibliothek, sofern verfügbar, und dem Desktop-OpenGL-Bundle opengl32.dll oder libgallium_wgl.dll sofern Letzteres verfügbar ist.
Der Lavapipe Vulkan CPU-Treiber ist seit 21.1.0 sowohl in MSVC- als auch in MinGW-Paketen verfügbar. Dateinamen: lvp_icd.x86_64.json , lvp_icd.x86.json , vulkan_lvp.dll . Beachten Sie, dass einige Programme möglicherweise Geräte vom Typ Vulkan CPU absichtlich ignorieren. Informationen zur Bereitstellung finden Sie in den Nutzungshinweisen.
Microsoft Dutzende Vulkan-Treiber sind seit 22.1.0 im MSVC-Paket und seit 22.2.0 auch im MinGW-Paket verfügbar. Dieser Treiber ist auf die D3D12-API angewiesen und kann auf unterstützten Systemen die GPU-Beschleunigung nutzen. Dateinamen: dzn_icd.x86_64.json , dzn_icd.x86.json , vulkan_dzn.dll . Informationen zur Bereitstellung finden Sie in den Nutzungshinweisen.
Der Vulkan-Treiber für AMD-Grafik (radv) ist gemäß @zmike-Vorschlag seit 22.1.0 nicht mehr verfügbar, da er in absehbarer Zeit nicht funktionieren wird. RADV war seit 21.2.0 sowohl in MSVC- als auch in MinGW-Paketen verfügbar. Die 32-Bit-Binärdatei davon war seit Mesa 22.0 verfügbar. Dateinamen: radeon_icd.x86_64.json , radeon_icd.x86.json , libvulkan_radeon.dll und vulkan_radeon.dll . Informationen zur Bereitstellung finden Sie in den Nutzungshinweisen.
Microsoft OpenCL-Stack. Dateinamen: clon12compiler.dll (Compiler), openclon12.dll (ICD) und WinPixEventRuntime.dll (nur x64-Abhängigkeit). Diese in 21.0.0 eingeführten Komponenten werden schließlich seit 21.3.0 (nur Compiler) bzw. 21.3.6-2 von mesa-dist-win bereitgestellt. Der CLonD3D12-Treiber ist als OpenCL-ICD verfügbar. Informationen zur Bereitstellung finden Sie in den Nutzungshinweisen. CLonD3D12 erfordert offiziell Windows 10 v10.0.19041.488 oder neuer und ist für die Neuverteilung auf DirectX IL angewiesen – dxil.dll zum Laden, das über Bereitstellungstools installiert werden kann. CLonD3D12 fungiert als Wrapper und gibt D3D12-API-Aufrufe zurück. Aufgrund dieser Beschaffenheit kann die D3D12-GPU-Beschleunigung verwendet werden, sofern verfügbar. Andernfalls wird das in Windows integrierte WARP-Software-Rendering verwendet. Bei Verwendung von WARP wurde CLonD3D12 zur Ankündigung von CL_DEVICE_TYPE_GPU verwendet, dies wurde jedoch in 23.0.0 zu CL_DEVICE_TYPE_CPU geändert, siehe microsoft/OpenCLOn12#19. Einige Programme ignorieren Treiber, bei denen CL_DEVICE_TYPE_CPU absichtlich festgelegt ist. Das alte Verhalten vor 23.0.0 kann seit Mesa 24.0.3 wiederhergestellt werden, indem der Wert der Umgebungsvariablen CLON12_WARP_IS_HARDWARE auf 1 gesetzt wird.
Der Clover OpenCL-Stack wurde aus dem Release-Paket in 22.1.1 entfernt, bis die Windows-Unterstützung abgeschlossen ist, da er derzeit unbrauchbar ist. Dateinamen: MesaOpenCL.dll (ICD), OpenCL.dll (eigenständige Laufzeit) und pipe_swrast.dll (Pipe Loader). Die Laufzeit kann mit dem Pro-App-Bereitstellungstool seit 21.3.7 oder in älteren Versionen per Kopieren und Einfügen zusammen mit allen verfügbaren Pipe-Loadern, von denen sie abhängt, bereitgestellt werden. Während der Bereitstellung verbirgt die Laufzeitumgebung alle anderen auf dem System vorhandenen OpenCL-ICDs und lässt die Software nur Mesa3D Clover als einzigen OpenCL-Treiber verwenden. Informationen zum Einsatz des ICD finden Sie in den Nutzungshinweisen.
Der D3D10-Software-Renderer ist seit 21.2.0 im MSVC-Paket verfügbar. Dateiname: d3d10sw.dll . Dies ist ein Ersatz für Microsoft WARP und leider gibt es keine saubere Möglichkeit, es bereitzustellen.
Das SPIR-V-zu-DXIL-Tool und die Bibliothek sind seit 21.0.0 im MSVC-Paket und seit 22.2.0 auch im MinGW-Paket verfügbar. Dateinamen: libspirv_to_dxil.dll , spirv_to_dxil.dll und spirv2dxil.exe .
VA-API D3D12-Treiber. Dateinamen: vaon12_drv_video.dll . Dieser Treiber wurde in 22.3.0 verfügbar gemacht. Genau wie GLonD3D12, CLonD3D12 und Dutzende ist dies ein mehrschichtiger Treiber, der auf der Direct3D 12-API läuft, sodass er, sofern verfügbar, GPU-Beschleunigung nutzen kann. Bereitstellungsanweisungen wurden von Microsoft dokumentiert. Das Bereitstellungstool pro Anwendung wurde aktualisiert, um diesen Prozess zu unterstützen.
Gallium-Rohschnittstelle. Diese veraltete Komponente wurde in Mesa3D 22.3.0 entfernt. Dateinamen: graw.dll , graw_null.dll . Dies ist ein Dummy-Gallium-Treiber ohne Grafik-API, der hauptsächlich zum Testen verwendet wird. Verfügbar für x86 und x64 sowie in der Vollversion (mit Windows-Systemunterstützung) und der Headless-Version (ohne Fenster). Seit 20.0.2 sind sowohl Versionen mit als auch ohne Fenster in den Paketen MSVC und MSYS2 Mingw-w64 verfügbar.
Testsuite. Viele ausführbare Unit-Tests.
Header und Bibliotheken für 32-Bit- und 64-Bit-Builds befinden sich in einem separaten Archiv namens Development Pack.
Ab 22.2.0 sind ein MSVC-Debug-Infopaket mit Debug-Symbolen im PDB-Format und ein für MinGW-Asserts aktiviertes, debug-optimiertes Build-Paket verfügbar. MinGW-Debug-Binärdateien können als Ersatz für ihre Release-Gegenstücke verwendet werden. Bei Software, die die Bereitstellung pro Anwendung verwendet, sollte dies nahtlos erfolgen, aber für eine systemweite Bereitstellung ist eine erneute Bereitstellung erforderlich, um von Release- zu Debug-Builds und umgekehrt zu wechseln. Weitere Informationen zum MinGW-Debugging finden Sie unter debug/mingw-start-debugging.sh
Wenn Sie meine Builds replizieren möchten, finden Sie hier Build-Anweisungen.
Wählen Sie zunächst zwischen Mingw- und MSVC-Paket. Weitere Informationen finden Sie im Abschnitt „Unterschiede zwischen MSVC- und MinGW-Paketen“. Schließen Sie vor dem Extrahieren des Release-Pakets alle Programme, die Mesa verwenden, sofern eines ausgeführt wird. Nach der Extraktion haben Sie Zugriff auf zwei Bereitstellungsoptionen, die sich beide in dem Verzeichnis befinden, in dem Sie Mesa installiert haben. Beide Bereitstellungsdienstprogramme verfügen über einen Neustartmechanismus, sodass Sie alle erforderlichen Bereitstellungen in einer Sitzung durchführen können. Die Bereitstellungstools unterstützen nur OpenGL- und OpenGL ES-Komponenten von Mesa3D sowie OpenCL Clover Standalone.
Ein systemweites Bereitstellungstool. Obwohl es für Systeme ohne hardwarebeschleunigte OpenGL-Unterstützung wie virtuelle Maschinen in Cloud-Umgebungen gedacht ist, kann es auch auf jedem Windows-System verwendet werden, um den OpenGL 1.1-Treiber für die Inbox-Software-Rendering zu ersetzen und die OpenGL-Unterstützung für Anwendungsfälle zu erweitern, in denen hardwarebeschleunigtes OpenGL nicht verfügbar ist, wie z. B. RDP-Verbindungen . Aufgrund möglicher Probleme mit Virtualbox-VMs unter Windows wird empfohlen, die 3D-Beschleunigung in solchen VMs zu deaktivieren, wenn der Mesa3D-Desktop-OpenGL-Treiber mithilfe des systemweiten Bereitstellungstools darin installiert ist, siehe Nr. 9.
Ein anwendungsspezifisches Bereitstellungstool, mit dem Mesa3D für ein einzelnes Programm bereitgestellt wird, unabhängig davon, ob hardwarebeschleunigte OpenGL-Unterstützung vorhanden ist oder nicht. Änderungen am Bereitstellungsdienstprogramm pro App sind dauerhaft und werden über Upgrades und Neuinstallationen hinweg beibehalten. Das Dienstprogramm zur Bereitstellung pro App hilft Ihnen, Speicherplatz zu sparen und vereinfacht die Arbeit, da Sie DLLs nicht manuell aus dem Mesa-Installationsverzeichnis kopieren müssen, da es symbolische Links zu den Mesa-Treibern erstellt, für deren Verwendung Sie sich entscheiden. Dieses Verhalten stellt sicher, dass alle Programme, die Mesa verwenden, dieselbe aktuelle Version verwenden. Das Dienstprogramm für die Bereitstellung pro App fragt nach dem Pfad zum Verzeichnis, das die ausführbare Datei der Anwendung und den Namen der ausführbaren Datei der Anwendung enthält (optional, kann leer bleiben, aber wenn es angegeben wird, kann es einige Programme zwingen, Mesa3D zu verwenden, wenn sie dies sonst nicht tun würden), wenn die App 64-Bit ist oder 32-Bit und die Treiber, die Sie benötigen. Bei 32-Bit-Anwendungen werden die Namen während der Ausführung im Task-Manager markiert. Die meisten Anwendungen verwenden Mesa unabhängig von den GPU-Fähigkeiten, aber einige Anwendungen sind möglicherweise intelligent genug, um OpenGL nur aus dem Systemverzeichnis zu laden. Durch die Angabe des Anwendungsdateinamens wird eine .local-Datei generiert, um die Anwendung zu zwingen, Mesa3D zu verwenden, wenn sie dies nicht möchte. Auch der Mesainjector von Federico Dossena kann zur Umgehung dieses Problems verwendet werden. Bauanleitung für Mesainjector.
Für alte Anwendungen von Anfang 200x und älter muss möglicherweise die Umgebungsvariable MESA_EXTENSION_MAX_YEAR festgelegt werden, siehe Abschnitt zur Kompatibilität älterer Software.
Anwendungen, die OpenGL 3.2 oder höher erfordern, benötigen möglicherweise eine Überschreibung der OpenGL-Kontextkonfiguration.
Beispiele zum Überschreiben der OpenGL-Kontextkonfiguration, zum Wechseln zu einem anderen Treiber und zur Kompatibilität alter Anwendungen finden Sie hier.
Die offizielle Mesa3D-Dokumentation ist hier verfügbar.
Die Bereitstellung von OpenCL-ICDs erfolgt durch Registrierung der ICD-Datei bei der OpenCL-Laufzeit des Systems (z. B. opencl.dll von Windowssystem32 ). Wenn Sie nicht über die OpenCL-Laufzeit Ihres Systems verfügen, können Sie diese erhalten, indem Sie die Intel OpenCL CPU-Laufzeit installieren. Es funktioniert auch für AMD-CPUs.
Die Bereitstellung für Vulkan-Treiber erfolgt über die Vulkan-Laufzeit mithilfe der ICD-Erkennungsmethode. Beachten Sie, dass die Vulkan-Laufzeitumgebung mit Grafiktreibern geliefert wird, die Vulkan unterstützen, sodass eine manuelle Installation möglicherweise nicht erforderlich ist.
Führen Sie die systemweite Bereitstellung aus und führen Sie den Deinstallationsvorgang durch, falls verfügbar, und beenden Sie ihn dann.
Laden Sie das Everything-Tool herunter und führen Sie es aus (jede Variante sollte funktionieren).
Führen Sie das Bereitstellungstool pro Anwendung aus und lassen Sie es laufen.
Geben Sie im Everything-Tool im Textfeld unter dem Menü libgallium_wgl.dll attrib:L und lassen Sie das Everything-Tool laufen;
Für jedes Suchergebnis im Everything-Tool:
Öffnen Sie den Speicherort im Windows Explorer über die Kontextmenüoption „Pfad öffnen“ oder „Dateispeicherort öffnen“.
Suchen Sie *.local-Dateien und entfernen Sie sie, aber nur, wenn Sie sicher sind, dass Sie bei der Bereitstellung an diesem Speicherort einen Dateinamen angegeben haben;
Kopieren Sie den Standort aus der Adressleiste und geben Sie ihn an das Bereitstellungstool für jede Anwendung weiter.
Senden Sie „Nein“ an alle Bereitstellungen, bis Sie aufgefordert werden, weitere Bereitstellungen durchzuführen. Senden Sie dort „Ja“.
Wiederholen Sie die Schritte 4 und 5 mit den Dateinamen osmesa.dll bzw. graw.dll, genauso wie es bei libgallium_wgl.dll der Fall war.
Schließen Sie die Bereitstellung pro Anwendung und Everything-Tools.
Machen Sie alle Registrierungsänderungen und alle Umgebungsvariablen rückgängig, die die Vulkan-Laufzeit für die Verwendung eines der Mesa3D-Vulkan-Treiber konfigurieren. Sehen Sie sich die Nutzungshinweise an, um Hinweise darauf zu erhalten, welche möglichen Änderungen Sie möglicherweise rückgängig machen müssen.
Wiederholen Sie Schritt 8, jedoch für OpenCL.
WARNUNG: Programme, bei denen bestimmte Dateien durch das jeweilige Anwendungsbereitstellungstool überschrieben wurden, müssen möglicherweise neu installiert/repariert werden. Das Bereitstellungstool pro Anwendung erkennt dieses Bereitstellungsszenario seit 22.0.0 und warnt davor.
Für alte Anwendungen von Anfang 200x und älter muss möglicherweise die Umgebungsvariable MESA_EXTENSION_MAX_YEAR festgelegt werden, um Pufferüberläufe zu vermeiden. Als Wert wird eine Jahreszahl erwartet, am häufigsten wird 2001 verwendet. Die von Mesa3D zurückgegebene Erweiterungsliste wird auf Erweiterungen reduziert, die bis einschließlich des angegebenen Jahres veröffentlicht wurden, da die Mesa3D-Erweiterungsliste nach Jahr sortiert ist.
Beispiel: set MESA_EXTENSION_MAX_YEAR=2001 . Siehe So legen Sie Umgebungsvariablen fest.
Mit der Veröffentlichung von OpenGL 3.1 wurden viele in OpenGL 3.0 als veraltet gekennzeichnete Funktionen entfernt und seit der Einführung von OpenGL 3.2 ist dieser Zweig der OpenGL-Spezifikation als OpenGL-Kernprofil bekannt. Außerdem wurde in OpenGL 3.3 ein neuer Zweig der OpenGL-Spezifikation eingeführt, der als vorwärtskompatibler Kontext bekannt ist und die veralteten OpenGL 3.0-Funktionen entfernt, die in OpenGL 3.1 nicht entfernt wurden. Die meisten proprietären Treiber haben die Ausnahmen von diesen Änderungen implementiert, die in Form der GL_ARB_compatibility-Erweiterung für OpenGL 3.1 und Kompatibilitätskontexten für OpenGL 3.2 und höher angeboten werden. Aufgrund der Komplexität und insbesondere des Mangels an korrekten Implementierungstests für GL_ARB_compatibility und Kompatibilitätskontexte entschieden sich die Mesa3D-Entwickler, die Arbeit in diesem Bereich zu verschieben, bis Mesa 18.1 die GL_ARB_compatibility-Unterstützung einführte und dann Mesa 21.3 die Kompatibilitätskontextunterstützung auf OpenGL 4.5 für llvmpipe erhöhte. Zusammenfassend lässt sich sagen, dass Programme, die einen OpenGL-Kompatibilitätskontext anfordern, nicht über OpenGL 3.0 für Mesa 18.0, 3.1 für Mesa 18.1 und 4.5 für Mesa 21.3 und neuer hinauskommen. Leider sind diese Art von Programmen unter Windows weit verbreitet, wo Entwickler dazu neigen, die Verwendung von Kontextflags zu vermeiden, die für das Kernprofil erforderlich sind. Glücklicherweise bietet Mesa3D einen Mechanismus zum Überschreiben des angeforderten OpenGL-Kontexts. Es gibt zwei Umgebungsvariablen, die die OpenGL-Kontextkonfiguration überschreiben:
MESA_GL_VERSION_OVERRIDE
Es wird verwendet, um die Version und den Typ des OpenGL-Kontexts anzugeben. Es erwartet einen Wert im folgenden Format
OpenGLMajorVersion.OpenGLMinorVersion{FC|COMPAT].
FC bedeutet einen vorwärtskompatiblen Kontext. COMPAT bedeutet, dass ein Kompatibilitätskontext für OpenGL 3.2 und neuer und GL_ARB_compatibility für OpenGL 3.1 aktiviert ist. Das Fehlen einer Zeichenfolge nach der Versionsnummer bedeutet, dass der Mesa3D-Standardkontexttyp für die angegebene OpenGL-Version wie folgt lautet: veraltete Funktionen für OpenGL 3.0 aktiviert, GL_ARB_compatibility für OpenGL 3.1 seit Mesa 18.1 aktiviert und Kernprofil für OpenGL 3.2 und höher. Beispiele: 3.3FC bedeutet OpenGL 3.3 vorwärtskompatiblen Kontext, 3.1COMPAT bedeutet OpenGL 3.1 mit GL_ARB_compatibility, 3.2 bedeutet OpenGL 3.2-Kernprofil. Der Standardwert für den llvmpipe-Treiber ist 4.5COMPAT für Mesa>=21.3, 3.1COMPAT für Mesa>=18.1 und 3.0COMPAT für Mesa<=18.0.
Eine sehr wichtige Funktion dieser Variable ist die Möglichkeit, einen unvollständigen OpenGL-Kontext zu konfigurieren. Programme können vom verwendeten Mesa3D-Treiber nur bis zum höchsten OpenGL-Kontext mit Khronos-Zertifizierung als vollständig anfordern. Derzeit ist llvmpipe in allen OpenGL-Profilen für OpenGL 4.5 zertifiziert. Derzeit sind swr und GLonD3D12 für OpenGL 3.3 im Kernprofil/vorwärtskompatiblen Kontext und 3.1 im Kompatibilitätsprofil zertifiziert. Die Unterstützung von Zink OpenGL hängt vom zugrunde liegenden Vulkan-Treiber ab. Seit Mesa 17.3 werden Werte erkannt, die für OpenGL 4.6 gedacht sind.
MESA_GLSL_VERSION_OVERRIDE
Wird verwendet, um die Version der Schattierungssprache anzugeben. Unterstützte Werte sind in Ganzzahlen umgewandelte Versionsnummern: 110, 120, 130, 140. 150, 330, 400, 410, 420, 430, 440, 450 und 460. Der Wert 460 wird erst seit Mesa 17.3 erkannt. Der Wert 130 entspricht beispielsweise GLSL 1.30. Es ist immer eine gute Idee, den OpenGL-Kontext und die Sprachversionen der Schattierung synchron zu halten, um Programmverwechslungen zu vermeiden, die zu Abstürzen oder Störungen führen können. Dies kann passieren, weil die meisten Anwendungen auf das Verhalten proprietärer Treiber angewiesen sind, um OpenGL- und GLSL-Versionen synchron zu halten. Hier ist die OpenGL-GLSL-Korrelationstabelle. Standardwerte für llvmpipe: 450 für Mesa 21.3, 140 für Mesa 18.1 und 130 für Mesa 18.0, wenn MESA_GL_VERSION_OVERRIDE undefiniert ist oder andernfalls mit dem Kernprofil übereinstimmt.
Unter Windows lassen sich Umgebungsvariablen am einfachsten durch das Schreiben von Batchdateien festlegen. Sie müssen dies höchstwahrscheinlich tun:
für jede Anwendung, die höhere OpenGL- und GLSL-Versionen erfordert, als standardmäßig vom ausgewählten Mesa3D-Treiber bereitgestellt werden;
wenn Sie einen nicht standardmäßigen Treiber für Desktop-OpenGL auswählen möchten;
wenn Sie die Erweiterungsliste kürzen müssen, um die Kompatibilität mit alten Programmen zu gewährleisten.
Öffnen Sie einfach Notepad und schreiben Sie das Batch-Skript. Beenden Sie beim Speichern den Dateinamen mit .bat oder .cmd, ändern Sie den Speichertyp auf „Alle Dateien“ und ändern Sie den Speicherort in den Speicherort, an dem sich die ausführbare Datei der Anwendung befindet. Wenn Sie sich mit Batch-Skripten auskennen, können Sie das aktuelle Verzeichnis während der Skriptausführung mit dem CD-Befehl ändern und so die Möglichkeit erhalten, das Skript an einem beliebigen Ort zu speichern, wie in den Beispielen für rpcs3 und GPU Caps Viewer gezeigt. Die Dokumentation der meisten von Mesa verwendeten Umgebungsvariablen ist hier verfügbar. Vollständige Beispiele finden Sie hier.
Sie können mehrere Umgebungsvariablen für dasselbe Batch-Skript festlegen, um die von Mesa3D bereitgestellten Funktionen zu kombinieren.
