Téléchargements
Parrainage
Problèmes connus
Différences entre les packages MSVC et MinGW
Contenu des packages Mingw et MSVC
Bibliothèques partagées communes OpenGL et OpenGL ES
Microsoft CLonD3D12, GLonD3D12, pilote Dozen Vulkan et dépendance commune D3D12 VA-API
Pilotes OpenGL de bureau
Pilote de rendu hors écran OpenGL
Pilotes OpenGL ES et bibliothèque EGL
Pilotes Vulkan
Pilotes, compilateurs et backends OpenCL
Pilotes, bibliothèques et outils Direct3D
Pilotes VA-API
Bibliothèque et outils de tests
Forfaits de développement
Packages de débogage
Construisez Mesa3D vous-même
Installation et utilisation
Notes d'utilisation
Désinstaller Mesa3D
Compatibilité des logiciels existants
Remplacement de la configuration du contexte OpenGL
Comment définir des variables d'environnement
Les builds Mesa 24.2.6 avec Visual Studio et MSYS2 Mingw-w64 sont désormais disponibles dans la section des versions.
Le projet mesa-dist-win a bénéficié d'un parrainage qui a été prolongé jusqu'au 1er novembre 2024. Le parrainage consiste en un VPS gratuit sur un nœud français à utiliser comme machine de build avec 12 Go de RAM, 6 threads AMD EPYC 7763 et 150 Go de SSD NVMe de Petrosky, une société d'hébergement de serveurs privés virtuels grâce à @Directox01.
Il s'agit d'une liste de tous les problèmes fréquemment rencontrés avec des solutions ou des solutions de contournement connues. Une version spécifique n’est affectée que par un sous-ensemble d’entre elles.
Erreur manquante libgallium_wgl.dll avec Mesa3D OpenGL ES et les pilotes OpenGL de bureau
Ceci se produit avec les déploiements par application existants effectués avec 21.2.x ou une version antérieure lors de la mise à jour vers 21.3.0 ou une version ultérieure. Refaites simplement le déploiement par application pour résoudre ce problème. La séparation du mégadriver Gallium et opengl32.dll était un changement très invasif contre lequel les déploiements existants par application n'avaient aucune chance. Si vous ne vous souvenez pas si un programme concerné est 32 bits ou 64 bits, cliquez avec le bouton droit sur le raccourci opengl32.dll dans le dossier où se trouve l'exécutable du programme et sélectionnez l'emplacement du fichier ouvert. Si l'emplacement se termine par x64, alors c'est 64 bits, sinon c'est 32 bits.
Erreur manquante libEGL.dll avec Mesa3D OpenGL ES
Ceci se produit avec les déploiements par application existants effectués avec 21.2.x ou une version antérieure lors de la mise à jour vers 21.3.0 ou une version ultérieure. Refaites simplement le déploiement par application pour résoudre ce problème. La prise en charge d'EGL était un changement très invasif contre lequel les déploiements existants par application n'avaient aucune chance. Si vous ne vous souvenez pas si un programme concerné est 32 bits ou 64 bits, cliquez avec le bouton droit sur le raccourci opengl32.dll dans le dossier où se trouve l'exécutable du programme et sélectionnez l'emplacement du fichier ouvert. Si l'emplacement se termine par x64, alors c'est 64 bits, sinon c'est 32 bits.
Erreur manquante libvulkan-1.dll avec Mesa3D opengl32.dll du package de version MinGW
Seules les versions antérieures à 22.2.0 pour lesquelles le pilote zink a été construit avec le groupe de packages MSYS2 MinGW-W64 vulkan-devel sont concernées. Exécutez fix-libvulkan-1.dll-missing-error.cmd à partir du package de version MinGW pour le corriger. Cet outil prend en charge l'exécution sans surveillance via l'option de ligne de commande auto . Cet outil n'est fourni dans le package de version MinGW qu'en cas de besoin, sinon il est intentionnellement manquant. La décision d'utiliser ce SDK Vulkan sur LunarG est prise en fonction du chargeur et des en-têtes les plus récents.
Les binaires 64 bits des packages MSVC et MinGW nécessitent un processeur avec AVX même s'ils ne devraient pas
Ce n'est plus un problème à partir de Mesa 22.0 ou version ultérieure. Ce problème est dû à des binaires 64 bits contenant le pilote swr qui divulguent l'utilisation d'AVX dans le code commun. Il s'agit d'un bug en amont signalé ici, ici et ici.
Mesa opengl32.dll du package MinGW dépend du runtime Vulkan depuis 21.0.0
Cela a été corrigé dans la version 22.2.0 en contenant cette exigence pour bloquer l'utilisation explicite du pilote Zink. Il s'agit d'une régression en amont introduite lorsque le pilote zink a été corrigé pour prendre en charge Windows.
Les programmes peuvent se comporter comme s'il n'y avait pas de support OpenGL lors de l'utilisation de Mesa opengl32.dll depuis 21.0.0
Il ne s'agit pas d'un défaut mais plutôt d'un changement de comportement de Mesa lorsque les variables d'environnement sont mal configurées. Cela se produit généralement lors de la sélection d'un pilote Mesa qui n'existe pas dans le package de version utilisé ou qui ne parvient pas à s'initialiser car le système hôte ne répond pas à la configuration matérielle requise ou manque de dépendances. La lecture des différences entre les packages MSVC et MinGW et le contenu des packages Mingw et MSVC devrait faciliter le dépannage.
Notes importantes sur les erreurs liées à l'absence libglapi.dll
Vous pouvez les rencontrer avec des programmes qui utilisent n'importe quel pilote OpenGL de bureau Mesa3D via un outil de déploiement par application, le déploiement à l'échelle du système n'est pas affecté. Vous pouvez en rencontrer si le déploiement par application a été effectué avant l'introduction de la prise en charge partagée de glapi. le glapi partagé est systématiquement disponible dans les packages MSVC et MinGW depuis la version 20.0.2.
Pour corriger ces erreurs, quelle qu'en soit la cause, vous devez redéployer. Si vous ne vous souvenez pas si un programme concerné est 32 bits ou 64 bits, cliquez avec le bouton droit sur le raccourci opengl32.dll dans le dossier où se trouve l'exécutable du programme et sélectionnez l'emplacement du fichier ouvert. Si l'emplacement se termine par x64, alors c'est 64 bits, sinon c'est 32 bits.
Le même problème avec la même solution s'applique à osmesa si vous effectuez une mise à niveau à partir de la version 17.3.5.501-1 ou d'une version antérieure.
Le package MinGW nécessite un processeur avec SSSE3 avec l'avantage de fournir une amélioration des performances de 3 à 5 % avec les pilotes de rendu logiciel ;
d3d10sw introduit dans la version 21.2.0 n'est disponible que dans le package MSVC.
Si vous devez migrer de Mingw vers les binaires MSVC, il vous suffit de remplacer le dossier des binaires Mesa du package Mingw par son homologue MSVC.
Les pilotes Mesa3D et artefacts de build suivants sont fournis dans chaque version :
Bibliothèque partagée GLAPI. Nom du fichier : libglapi.dll . Sa présence est requise lors de la prise en charge d'OpenGL et d'OpenGL ES. Le moteur de rendu hors écran Mesa3D et tous les pilotes Mesa3D OpenGL et OpenGL ES en dépendent lorsqu'ils sont présents. Depuis la version 20.0.2, il est disponible dans les packages MSVC et MSYS2 Mingw-w64.
Mégapilote Gallium OpenGL. Nom du fichier : libgallium_wgl.dll . Lorsqu'il est présent, il contient tous les pilotes OpenGL du bureau Mesa3D au lieu de opengl32.dll . Il a fait ses débuts dans la version 21.3.0. La bibliothèque Mesa3D EGL et les pilotes OpenGL ES en dépendent lorsqu'ils sont présents.
Exécution Mesa3D WGL. Nom du fichier : opengl32.dll . Celui-ci contenait auparavant tous les pilotes OpenGL du bureau Mesa3D et OpenGL ES en dépendait, mais depuis 21.3.0, il a été réduit à n'être qu'un chargeur pour le mégapilote OpenGL au gallium, donc seuls les programmes utilisant les pilotes OpenGL du bureau Mesa3D via un déploiement par application en dépendent. maintenant.
DirectX IL pour la redistribution. Nom du fichier : dxil.dll . Ce redistribuable binaire est fourni dans le SDK Windows et le compilateur DirectX Shader et emballé pendant le processus de publication. Les outils de déploiement l'installent si nécessaire.
llvmpipe. llvmpipe est un moteur de rendu logiciel Desktop OpenGL destiné à servir de solution de secours lorsque l'accélération matérielle n'est pas possible. Il ne peut gérer que des jeux très légers avec de bonnes performances. Il s'agit du pilote OpenGL de bureau Mesa3D par défaut lorsque GLonD3D12 est indisponible ou ne parvient pas à se charger. Il est disponible pour x86 et x64 dans le cadre du bundle Mesa3D Desktop OpenGL opengl32.dll ou libgallium_wgl.dll si ce dernier est disponible. Lorsqu'il ne s'agit pas du pilote par défaut, sélectionnez-le en définissant la variable d'environnement GALLIUM_DRIVER=llvmpipe .
softpipe est une implémentation de référence d'un moteur de rendu logiciel Desktop OpenGL sans se concentrer sur les performances de jeu. Il est disponible pour x86 et x64 dans le cadre du bundle Mesa3D Desktop OpenGL opengl32.dll ou libgallium_wgl.dll si ce dernier est disponible. Sélectionnez-le en définissant la variable d'environnement GALLIUM_DRIVER=softpipe .
GLOND3D12. Il est disponible pour x86 et x64 dans le package MSVC et depuis 22.2.0 dans le package MinGW ainsi que dans le cadre du bundle Mesa3D Desktop OpenGL opengl32.dll ou libgallium_wgl.dll si ce dernier est disponible et avant 22.3.0 en tant openglon12.dll autonome. aussi. En plus d'exiger officiellement Windows 10 v10.0.19041.488 ou plus récent, cela dépend également de DirectX IL pour la redistribution - dxil.dll à charger, qui peut être installé via des outils de déploiement. Lorsqu'il est disponible et s'il peut être chargé, il s'agit du pilote OpenGL de bureau Mesa3D par défaut sur les systèmes accélérés par GPU D3D12. Ce pilote introduit dans la version 21.0.0 fonctionne comme un wrapper renvoyant les appels API D3D12. En raison de cette nature, il peut utiliser l’accélération GPU. S'il n'est pas sélectionné par défaut, vous pouvez le tester avec le moteur de rendu du logiciel Direct3D WARP intégré à Windows en définissant les variables d'environnement GALLIUM_DRIVER=d3d12 et LIBGL_ALWAYS_SOFTWARE=1 . La copie autonome n'a pas besoin d'être définie sur GALLIUM_DRIVER=d3d12 et elle ne peut être installée que via un outil de déploiement à l'échelle du système. Les bundles autonomes GLonD3D12 et Mesa3D Desktop OpenGL se remplacent lors de l'utilisation d'un outil de déploiement à l'échelle du système, mais vous pouvez l'inverser à tout moment.
du zinc. Ce pilote introduit dans le package MinGW dans la version 21.0.0 et dans le package MSVC dans la version 21.2.0 est disponible pour x86 et x64 dans le cadre du bundle Mesa3D Desktop OpenGL opengl32.dll ou libgallium_wgl.dll si ce dernier est disponible. De la même manière que GLonD3D12, il fonctionne comme un wrapper renvoyant les appels de l'API Vulkan. En raison de cette nature, il utilise l'accélération GPU par défaut, mais il prend également en charge le rendu logiciel. Sélectionnez-le via la variable d'environnement GALLIUM_DRIVER=zink , mais notez qu'il nécessite au moins 1 périphérique Vulkan et un chargeur/runtime Vulkan pour s'initialiser. zink a ignoré les périphériques de type CPU Vulkan par défaut jusqu'à la version 22.1.0. De nos jours, il utilise un système de priorité qui sélectionne automatiquement un périphérique de type CPU Vulkan s'il n'existe aucun périphérique de type Vulkan de priorité plus élevée. Vous pouvez tester Zink avec des appareils de type CPU Vulkan uniquement en définissant LIBGL_ALWAYS_SOFTWARE=1 (Mesa 22.1.0 et versions ultérieures) ou ZINK_USE_LAVAPIPE=true (obsolète dans Mesa 22.1.0).
swr. Ce pilote n'est plus disponible dans Mesa 22.0 et versions ultérieures. Noms de fichiers : swrAVX.dll , swrAVX2.dll , swrSKX.dll , swrKNL.dll . Même s'il réside en dehors du bundle Mesa3D Desktop OpenGL opengl32.dll ou libgallium_wgl.dll si ce dernier est disponible, il en dépend toujours. Ce pilote de rendu logiciel OpenGL de bureau alternatif développé par Intel est optimisé pour les logiciels de visualisation. Il est disponible dans le package MSVC et depuis 20.1.7 dans le package MinGW également. Il ne prend en charge que x64, x86 n'est officiellement pas pris en charge. Il existe actuellement 4 DLL, une seule étant chargée en fonction de ce que le processeur de l'utilisateur peut faire. Vous pouvez passer à swr en définissant la valeur de la variable d'environnement GALLIUM_DRIVER sur swr.
osmesa. Nom du fichier : osmesa.dll . Disponible pour x86 et x64. Ce pilote est utilisé dans des cas particuliers par des logiciels conçus pour utiliser le code Mesa pour effectuer un rendu sans aucune dépendance au système de fenêtre ou au système d'exploitation. Depuis la version 21.0.0, seul l'osmesa gallium est resté. Il prend en charge OpenGL 3.x et versions ultérieures. Depuis la version 20.0.2, l'intégration d'osmesa avec les pilotes GLLES autonomes est disponible dans les packages MSVC et MSYS2 Mingw-w64 nécessitant libglapi.dll dans le processus.
Bibliothèque EGL. Nom du fichier : libEGL.dll . Bibliothèque Mesa3D EGL utilisée par les pilotes OpenGL ES. Cela a fait ses débuts dans la version 21.3.0 et est disponible pour les applications 32 bits et 64 bits dans les packages MSVC et MSYS2. Cela dépend du bundle OpenGL de bureau opengl32.dll ou libgallium_wgl.dll si ce dernier est disponible.
Pilotes autonomes OpenGL ES. Noms de fichiers : libGLESv1_CM.dll et libGLESv2.dll . Pilotes autonomes OpenGL ES 1.x, 2.x et 3.x disponibles pour les applications 32 bits et 64 bits. Depuis la version 20.0.2, ils sont disponibles dans les packages MSVC et MSYS2 Mingw-w64. Ils dépendent de la bibliothèque Mesa3D EGL si disponible et du bundle OpenGL de bureau opengl32.dll ou libgallium_wgl.dll si ce dernier est disponible.
Le pilote CPU lavapipe Vulkan est disponible dans les packages MSVC et MinGW depuis la version 21.1.0. Noms de fichiers : lvp_icd.x86_64.json , lvp_icd.x86.json , vulkan_lvp.dll . Notez que certains programmes peuvent ignorer volontairement les périphériques de type CPU Vulkan. Pour plus d’informations sur la façon de déployer, consultez les notes d’utilisation.
Le pilote Microsoft douzaine Vulkan est disponible depuis 22.1.0 dans le package MSVC et depuis 22.2.0 dans le package MinGW également. Ce pilote s'appuie sur l'API D3D12 pour fonctionner et peut utiliser l'accélération GPU sur les systèmes pris en charge. Noms de fichiers : dzn_icd.x86_64.json , dzn_icd.x86.json , vulkan_dzn.dll . Pour plus d’informations sur la façon de déployer, consultez les notes d’utilisation.
Le pilote Vulkan pour les graphiques AMD (radv) n'est plus disponible depuis la version 22.1.0 selon la suggestion de @zmike car il ne fonctionnera pas de sitôt. RADV était disponible dans les packages MSVC et MinGW depuis la version 21.2.0. Le binaire 32 bits était disponible depuis Mesa 22.0. Noms de fichiers : radeon_icd.x86_64.json , radeon_icd.x86.json , libvulkan_radeon.dll et vulkan_radeon.dll . Pour plus d’informations sur la façon de déployer, consultez les notes d’utilisation.
Pile Microsoft OpenCL. Noms de fichiers : clon12compiler.dll (compilateur), openclon12.dll (ICD) et WinPixEventRuntime.dll (dépendance x64 uniquement). Ces composants introduits en 21.0.0 sont finalement fournis par mesa-dist-win depuis respectivement 21.3.0 (compilateur uniquement) et 21.3.6-2. Le pilote CLonD3D12 est disponible sous forme d'ICD OpenCL. Pour plus d’informations sur la façon de déployer, consultez les notes d’utilisation. CLonD3D12 nécessite officiellement Windows 10 v10.0.19041.488 ou plus récent et dépend de DirectX IL pour la redistribution - dxil.dll à charger, qui peut être installé via des outils de déploiement. CLonD3D12 fonctionne comme un wrapper renvoyant les appels d'API D3D12. En raison de cette nature, il peut utiliser l'accélération GPU D3D12 si disponible, sinon le rendu du logiciel WARP intégré à Windows est utilisé. Lors de l'utilisation de WARP, CLonD3D12 était utilisé pour annoncer CL_DEVICE_TYPE_GPU, mais cela a changé dans la version 23.0.0 en CL_DEVICE_TYPE_CPU, voir Microsoft/OpenCLOn12#19. Certains programmes ignorent les pilotes avec CL_DEVICE_TYPE_CPU volontairement défini. L'ancien comportement antérieur à 23.0.0 peut être restauré depuis Mesa 24.0.3 en définissant la valeur de la variable d'environnement CLON12_WARP_IS_HARDWARE sur 1.
La pile OpenCL de clover a été supprimée du package de version 22.1.1 jusqu'à ce que la prise en charge de Windows soit finalisée car elle est actuellement inutilisable. Noms de fichiers : MesaOpenCL.dll (ICD), OpenCL.dll (exécution autonome) et pipe_swrast.dll (chargeur de tuyaux). Le runtime peut être déployé avec un outil de déploiement par application depuis 21.3.7 ou sur des versions antérieures par copier-coller avec tous les chargeurs de tuyaux disponibles dont il dépend. Lors du déploiement, le moteur d'exécution masque tous les autres ICD OpenCL présents sur le système et permet uniquement au logiciel d'utiliser le trèfle Mesa3D comme seul pilote OpenCL. Pour plus d’informations sur la façon de déployer l’ICD, consultez les notes d’utilisation.
Le moteur de rendu logiciel D3D10 est disponible dans le package MSVC depuis la version 21.2.0. Nom du fichier : d3d10sw.dll . Il s'agit d'un remplacement immédiat de Microsoft WARP et, malheureusement, il n'existe aucun moyen propre de le déployer.
L'outil et la bibliothèque SPIR-V vers DXIL sont également disponibles dans le package MSVC depuis 21.0.0 et depuis 22.2.0 dans le package MinGW. Noms de fichiers : libspirv_to_dxil.dll , spirv_to_dxil.dll et spirv2dxil.exe .
Pilote VA-API D3D12. Noms de fichiers : vaon12_drv_video.dll . Ce pilote a été rendu disponible dans la version 22.3.0. Tout comme GLonD3D12, CLonD3D12 et douzaines, il s'agit d'un pilote en couches fonctionnant sur l'API Direct3D 12 afin qu'il puisse utiliser l'accélération GPU si disponible. Les instructions de déploiement ont été documentées par Microsoft. L'outil de déploiement par application a été mis à jour pour faciliter ce processus.
Interface brute en gallium. Ce composant obsolète a été supprimé dans Mesa3D 22.3.0. Noms de fichiers : graw.dll , graw_null.dll . Il s'agit d'un pilote Gallium factice sans aucune API graphique, principalement utilisé pour les tests. Disponible pour x86 et x64 et en versions complètes (avec prise en charge du système de fenêtre) et sans tête (sans fenêtre). Depuis la version 20.0.2, les versions avec et sans fenêtre sont disponibles dans les packages MSVC et MSYS2 Mingw-w64.
suite de tests. De nombreux tests unitaires exécutables.
Les en-têtes et les bibliothèques des versions 32 bits et 64 bits se trouvent dans une archive distincte appelée pack de développement.
À partir de la version 22.2.0, un package d'informations de débogage MSVC contenant des symboles de débogage au format PDB et un package de construction optimisé pour le débogage activé MinGW est disponible. Les binaires de débogage MinGW peuvent être utilisés en remplacement de leurs homologues de version. Avec un logiciel utilisant un déploiement par application, cela devrait être transparent, mais pour un déploiement à l'échelle du système, un redéploiement est nécessaire pour passer de la version aux versions de débogage et vice versa. Pour plus d'informations sur le débogage MinGW, consultez debug/mingw-start-debugging.sh
Les instructions de build, si vous souhaitez répliquer mes builds, sont disponibles ici.
Choisissez d’abord entre les packages Mingw et MSVC. Voir la section Différences entre les packages MSVC et MinGW pour plus de détails. Avant d'extraire le package de version, fermez tous les programmes qui utilisent Mesa, le cas échéant. Après l'extraction, vous aurez accès à 2 options de déploiement, toutes deux situées dans le répertoire dans lequel vous avez installé Mesa. Les deux utilitaires de déploiement disposent d'un mécanisme de redémarrage qui vous permet d'effectuer tous les déploiements dont vous avez besoin en une seule session. Les outils de déploiement prennent uniquement en charge les composants OpenGL et OpenGL ES de Mesa3D plus OpenCL Clover autonome.
Un outil de déploiement à l’échelle du système. Bien que destiné aux systèmes dépourvus de prise en charge d'OpenGL à accélération matérielle, comme les machines virtuelles dans les environnements cloud, il peut également être utilisé sur n'importe quel système Windows pour remplacer le pilote OpenGL 1.1 de rendu du logiciel de boîte de réception étendant la prise en charge d'OpenGL pour les cas d'utilisation où OpenGL à accélération matérielle n'est pas disponible comme les connexions RDP. . En raison de problèmes potentiels avec les machines virtuelles Virtualbox exécutant Windows, il est recommandé de désactiver l'accélération 3D dans ces machines virtuelles si le pilote OpenGL du bureau Mesa3D y est installé à l'aide de l'outil de déploiement à l'échelle du système, voir #9.
Un outil de déploiement par application, utilisé pour déployer Mesa3D pour un seul programme, que la prise en charge OpenGL accélérée par le matériel soit présente ou non. Les modifications apportées à l'utilitaire de déploiement par application sont persistantes et sont conservées lors des mises à niveau et des réinstallations. L'utilitaire de déploiement par application vous aide à économiser de l'espace de stockage et facilite les choses car vous n'aurez pas à copier manuellement les DLL du répertoire d'installation de Mesa car il crée des liens symboliques vers les pilotes Mesa que vous choisissez d'utiliser. Ce comportement garantit que tous les programmes qui utilisent Mesa utilisent la même version à jour. L'utilitaire de déploiement par application demande le chemin d'accès au répertoire contenant l'exécutable de l'application, le nom du fichier exécutable de l'application (facultatif, il peut rester vide mais s'il est spécifié, il peut forcer certains programmes à utiliser Mesa3D alors qu'ils ne le feraient pas autrement), si l'application est 64 bits ou 32 bits et les pilotes dont vous avez besoin. Les applications 32 bits voient leur nom marqué dans le Gestionnaire des tâches lors de leur exécution. La plupart des applications utiliseront Mesa quelles que soient les capacités du GPU, mais certaines applications peuvent être suffisamment intelligentes pour charger OpenGL uniquement à partir du répertoire système. En fournissant le nom de fichier de l'application, un fichier .local est généré pour tenter de forcer l'application à utiliser Mesa3D lorsqu'elle ne le souhaite pas. En outre, Mesainjector de Federico Dossena peut également être utilisé pour contourner ce problème. Instructions de construction pour Mesainjector.
Les anciennes applications du début des versions 200x et antérieures peuvent nécessiter le jeu de variables d'environnement MESA_EXTENSION_MAX_YEAR, voir la section sur la compatibilité des logiciels existants.
Les applications nécessitant OpenGL 3.2 ou une version plus récente peuvent nécessiter un remplacement de la configuration du contexte OpenGL.
Des exemples de remplacement de la configuration du contexte OpenGL, de passage à un autre pilote et de compatibilité avec les anciennes applications sont disponibles ici.
La documentation officielle de Mesa3D est disponible ici.
Le déploiement des ICD OpenCL se fait via l'enregistrement du fichier ICD avec le runtime du système OpenCL (par exemple opencl.dll de Windowssystem32 ). Si vous ne disposez pas du runtime OpenCL du système, vous pouvez l'obtenir en installant le runtime du processeur Intel OpenCL. Cela fonctionne également pour les processeurs AMD.
Le déploiement des pilotes Vulkan s'effectue via le runtime Vulkan à l'aide de la méthode de découverte ICD. Notez que le runtime Vulkan est fourni avec des pilotes graphiques prenant en charge Vulkan, son installation manuelle peut donc ne pas être nécessaire.
Exécutez le déploiement à l'échelle du système et effectuez l'opération de désinstallation si disponible, puis quittez ;
Téléchargez et exécutez l'outil Everything (n'importe quelle version devrait fonctionner) ;
Exécutez l'outil de déploiement d'application par application et laissez-le fonctionner ;
Dans l'outil Everything, dans le champ de texte du menu, entrez libgallium_wgl.dll attrib:L et laissez l'outil Everything fonctionner ;
Pour chaque résultat de recherche dans l’outil Tout :
ouvrez son emplacement dans l'Explorateur Windows via l'option de menu contextuel Ouvrir le chemin ou Ouvrir l'emplacement du fichier ;
recherchez les fichiers *.local et supprimez-les, mais uniquement si vous êtes certain d'avoir spécifié un nom de fichier lors du déploiement à cet emplacement ;
copiez l'emplacement à partir de la barre d'adresse et transmettez-le à chaque outil de déploiement d'application ;
envoyez non à tous les déploiements jusqu'à ce que l'on vous demande d'effectuer d'autres déploiements, envoyez oui ici.
Répétez les étapes 4 et 5 en utilisant respectivement les noms de fichiers osmesa.dll et graw.dll de la même manière que pour libgallium_wgl.dll ;
Fermer le déploiement par application et les outils Everything ;
Annulez toutes les modifications du registre et toutes les variables d'environnement qui configurent le runtime Vulkan pour utiliser l'un des pilotes Mesa3D Vulkan, consultez les notes d'utilisation pour obtenir des indices sur les modifications potentielles que vous devrez peut-être annuler ;
Répétez l'étape 8, mais pour OpenCL.
AVERTISSEMENT : les programmes pour lesquels certains fichiers ont été écrasés par l'outil de déploiement d'application peuvent nécessiter une réinstallation/réparation. L'outil de déploiement par application détecte et avertit de ce scénario de déploiement depuis 22.0.0.
Les anciennes applications du début des versions 200x et antérieures peuvent nécessiter la définition de la variable d'environnement MESA_EXTENSION_MAX_YEAR pour éviter les débordements de tampon. Il attend un numéro d'année comme valeur, le plus couramment utilisé étant 2001. Il réduit la liste d'extensions renvoyée par Mesa3D aux extensions publiées jusqu'à l'année fournie incluse, car la liste des extensions Mesa3D est triée par année.
Ex : set MESA_EXTENSION_MAX_YEAR=2001 . Voir Comment définir des variables d'environnement.
Avec la sortie d'OpenGL 3.1, de nombreuses fonctionnalités marquées comme obsolètes dans OpenGL 3.0 ont été supprimées et depuis le lancement d'OpenGL 3.2, cette branche de spécification OpenGL est connue sous le nom de profil principal OpenGL. Également dans OpenGL 3.3, une nouvelle branche de la spécification OpenGL connue sous le nom de contexte de compatibilité ascendante a été introduite, qui supprime les fonctionnalités obsolètes d'OpenGL 3.0 qui n'ont pas été supprimées dans OpenGL 3.1. La plupart des pilotes propriétaires ont implémenté les exemptions de ces modifications proposées sous la forme d'une extension GL_ARB_compatibility pour OpenGL 3.1 et de contextes de compatibilité pour OpenGL 3.2 et supérieur. En raison de la complexité et surtout du manque de tests d'implémentation corrects pour GL_ARB_compatibility et les contextes de compatibilité, les développeurs de Mesa3D ont choisi de retarder le travail dans ce domaine jusqu'à ce que Mesa 18.1 introduise la prise en charge de GL_ARB_compatibility, puis Mesa 21.3 a transféré la prise en charge des contextes de compatibilité vers OpenGL 4.5 pour llvmpipe. En conclusion, les programmes demandant un contexte de compatibilité OpenGL ne dépasseront pas OpenGL 3.0 pour Mesa 18.0, 3.1 pour Mesa 18.1 et 4.5 pour Mesa 21.3 et versions ultérieures. Malheureusement, ce type de programmes est répandu sous Windows, où les développeurs ont tendance à éviter d'utiliser les indicateurs de contexte requis par le profil principal. Heureusement Mesa3D fournit un mécanisme pour remplacer le contexte OpenGL demandé. Il existe 2 variables d'environnement qui remplacent la configuration du contexte OpenGL :
MESA_GL_VERSION_OVERRIDE
Il est utilisé pour spécifier la version et le type du contexte OpenGL. Il attend une valeur au format suivant
OpenGLMajorVersion.OpenGLMinorVersion{FC|COMPAT].
FC signifie un contexte compatible ascendant. COMPAT signifie un contexte de compatibilité pour OpenGL 3.2 et plus récent et GL_ARB_compatibility activé pour OpenGL 3.1. L'absence de chaîne après le numéro de version signifie le type de contexte par défaut de Mesa3D pour la version OpenGL spécifié, qui est le suivant : fonctionnalités obsolètes activées pour OpenGL 3.0, compatibilité GL_ARB activée pour OpenGL 3.1 depuis Mesa 18.1 et profil de base pour OpenGL 3.2 et supérieur. Exemples : 3.3FC signifie contexte compatible avec OpenGL 3.3, 3.1COMPAT signifie OpenGL 3.1 avec GL_ARB_compatibility , 3.2 signifie profil de base OpenGL 3.2. La valeur par défaut du pilote llvmpipe est 4.5COMPAT pour Mesa>=21.3, 3.1COMPAT pour Mesa>=18.1 et 3.0COMPAT pour Mesa<=18.0.
Une fonctionnalité très importante fournie par cette variable est la possibilité de configurer un contexte OpenGL incomplet. Les programmes ne peuvent demander que le contexte OpenGL le plus élevé avec la certification Khronos complète à partir du pilote Mesa3D utilisé. Actuellement, llvmpipe est certifié pour OpenGL 4.5 dans tous les profils OpenGL. Actuellement, swr et GLonD3D12 sont certifiés pour OpenGL 3.3 dans le profil de base/contexte de compatibilité ascendante et 3.1 dans le profil de compatibilité. La prise en charge de zink OpenGL dépend du pilote Vulkan sous-jacent. Depuis Mesa 17.3, les valeurs destinées à OpenGL 4.6 sont reconnues.
MESA_GLSL_VERSION_OVERRIDE
Utilisé pour spécifier la version du langage d'ombrage. Les valeurs prises en charge sont les numéros de version convertis en nombre entier : 110, 120, 130, 140. 150, 330, 400, 410, 420, 430, 440, 450 et 460. La valeur 460 n'est reconnue que depuis Mesa 17.3. La valeur 130 par exemple correspond à GLSL 1.30. C'est toujours une bonne idée de synchroniser le contexte OpenGL et les versions du langage d'ombrage pour éviter toute confusion dans les programmes qui pourrait entraîner des plantages ou des problèmes. Cela peut se produire parce que la plupart des applications s'appuient sur le comportement des pilotes propriétaires consistant à synchroniser les versions OpenGL et GLSL. Voici le tableau de corrélation OpenGL - GLSL. Valeurs par défaut pour llvmpipe : 450 pour Mesa 21.3, 140 pour Mesa 18.1 et 130 pour Mesa 18.0 si MESA_GL_VERSION_OVERRIDE n'est pas défini ou correspond au profil principal dans le cas contraire.
Sous Windows, le moyen le plus simple de définir des variables d'environnement consiste à écrire des fichiers batch. Vous devrez probablement le faire :
pour chaque application nécessitant des versions OpenGL et GLSL supérieures à celles exposées par défaut par le pilote Mesa3D sélectionné ;
si vous souhaitez sélectionner un pilote autre que celui par défaut pour le bureau OpenGL ;
si vous devez réduire la liste des extensions pour assurer la compatibilité des anciens programmes.
Ouvrez simplement le Bloc-notes, écrivez le script batch. Lors de l'enregistrement, terminez le nom du fichier par .bat ou .cmd, remplacez le type de sauvegarde par tous les fichiers et modifiez l'emplacement de sauvegarde par celui où se trouve l'exécutable de l'application. Si vous avez des compétences avec les scripts batch, vous pouvez modifier le répertoire actuel pendant l'exécution du script à l'aide de la commande CD, ouvrant la possibilité d'enregistrer le script où vous le souhaitez, comme indiqué dans les exemples rpcs3 et GPU Caps Viewer. La documentation de la plupart des variables d'environnement utilisées par Mesa est disponible ici. Des exemples complets sont disponibles ici.
Vous pouvez définir plusieurs variables d'environnement sur le même script batch pour mélanger les fonctionnalités fournies par Mesa3D.
