Mesa 24.1.3 builds with Visual Studio and MSYS2 Mingw-w64 are now available in releases section.
mesa-dist-win project was given a sponsorship that was extended until November 1st 2024. Sponsorship consists in a free VPS to use as build machine with 12 GB RAM, 6 threads AMD EPYC 7542 and 150 GB NVMe SSD from Petrosky, a virtual private server hosting company thanks to @Directox01.
This is a list of all comonly encountered issues with known solutions or workarounds. A specific release is only affected by a subset of them.
libgallium_wgl.dll
missing error with Mesa3D OpenGL ES and desktop OpenGL driversThis is encountered with existing per application deployments made with 21.2.x or older when updating to 21.3.0 or newer. Just redo per app deployment to fix it. Gallium megadriver separation from opengl32.dll
was a very invasive change that existing per app deployments didn't stand a chance against. If you don't remember if an affected program is 32-bit or 64-bit, right click on opengl32.dll
shortcut in the folder where the program executable is located and select open file location. If location ends in x64 then it's 64-bit, otherwise it's 32-bit.
libEGL.dll
missing error with Mesa3D OpenGL ESThis is encountered with existing per application deployments made with 21.2.x or older when updating to 21.3.0 or newer. Just redo per app deployment to fix it. The EGL support was a very invasive change that existing per app deployments didn't stand a chance against. If you don't remember if an affected program is 32-bit or 64-bit, right click on opengl32.dll
shortcut in the folder where the program executable is located and select open file location. If location ends in x64 then it's 64-bit, otherwise it's 32-bit.
libvulkan-1.dll
missing error with Mesa3D opengl32.dll
from MinGW release packageOnly releases prior to 22.2.0 for which zink driver was built with MSYS2 MinGW-W64 vulkan-devel package group are affected. Run fix-libvulkan-1.dll-missing-error.cmd
from MinGW release package to correct it. This tool supports unattended execution via auto
command line option. This tool is only bundled in MinGW release package when needed otherwise it's intentionally missing. The decision to use this Vulkan SDK over LunarG's is done based on which comes with newer loader and headers.
This is no longer an issue as of Mesa 22.0 or newer. This issue is caused by 64-bit binaries containing swr driver which leaks AVX usage into common code. This is an upstream bug reported here, here and here.
Mesa opengl32.dll
from MinGW package depends on Vulkan runtime since 21.0.0
This was fixed in 22.2.0 by containing this requirement to zink driver explicit usage. This is an upstream regression introduced when zink driver was patched to support Windows.
opengl32.dll
since 21.0.0This is not a defect but rather a behavior change of Mesa when environment variables are misconfigured. It usually happens when selecting a Mesa driver that doesn't exist in release package used or it fails to initialize due to host system not meeting hardware requirements or lacking dependencies. Reading differences between MSVC and MinGW packages and Mingw and MSVC Package contents should aid in troubleshooting.
libglapi.dll
You may experience them with programs that use any Mesa3D desktop OpenGL driver via per app deployment tool, system wide deployment is unaffected. You may experience them if per app deployment was done before shared glapi support was introduced. shared glapi has been consistently available in both MSVC and MinGW packages since 20.0.2.
To correct these errors regardless of cause you have to re-deploy. If you don't remember if an affected program is 32-bit or 64-bit, right click on opengl32.dll
shortcut in the folder where the program executable is located and select open file location. If location ends in x64 then it's 64-bit, otherwise it's 32-bit.
Same problem with same solution applies to osmesa if you are upgrading from 17.3.5.501-1 or older.
If you need to migrate from Mingw to MSVC binaries you just need to replace Mesa binaries folder from Mingw package with MSVC counterpart.
The following Mesa3D drivers and build artifacts are shipped in each release:
libglapi.dll
. Its presence is required when providing both OpenGL and OpenGL ES support. Mesa3D off-screen renderer and all Mesa3D OpenGL and OpenGL ES drivers depend on it when present. Since 20.0.2 it's available in both MSVC and MSYS2 Mingw-w64 packages.libgallium_wgl.dll
. When present it contains all Mesa3D desktop OpenGL drivers instead of opengl32.dll
. It debuted in 21.3.0. Mesa3D EGL library and OpenGL ES drivers depend on it when present.opengl32.dll
. This used to contain all Mesa3D desktop OpenGL drivers and OpenGL ES depended on it, but since 21.3.0 it was reduced to only being a loader for gallium OpenGL megadriver, so only programs using Mesa3D desktop OpenGL drivers via per-application deployment depend on it now.
dxil.dll
. This binary redistributable is provided in Windows SDK and DirectX Shader Compiler and packaged during release process. Deployment tools install it as necessary.
opengl32.dll
or libgallium_wgl.dll
if the latter is available. When it's not the default driver select it by setting environment variable GALLIUM_DRIVER=llvmpipe
.opengl32.dll
or libgallium_wgl.dll
if the latter is available. Select it by setting environment variable GALLIUM_DRIVER=softpipe
.opengl32.dll
or libgallium_wgl.dll
if the latter is available and prior to 22.3.0 as standalone openglon12.dll
as well. In addition to officially requiring Windows 10 v10.0.19041.488 or newer, it also depends on DirectX IL for redistribution - dxil.dll
to load, which can be installed via deployment tools. When available and if it can load, this is the default Mesa3D desktop OpenGL driver on D3D12 GPU accelerated systems. This driver introduced in 21.0.0 is operating as wrapper returning D3D12 API calls. Due to this nature it can use GPU acceleration. If it's not selected by default you can test it with Direct3D WARP software renderer built into Windows by setting GALLIUM_DRIVER=d3d12
and LIBGL_ALWAYS_SOFTWARE=1
environment variables. The standalone copy doesn't need GALLIUM_DRIVER=d3d12
being set and it can only be installed via system-wide deployment tool. The standalone GLonD3D12 and Mesa3D Desktop OpenGL bundle replace each other when using system-wide deployment tool but you can reverse it any time. opengl32.dll
or libgallium_wgl.dll
if the latter is available. Similarly to GLonD3D12, it operates as wrapper returning Vulkan API calls. Due to this nature it uses GPU acceleration by default but it supports software rendering too. Select it via GALLIUM_DRIVER=zink
environment variable, but note that it requires at least 1 Vulkan device and Vulkan loader/runtime to initialize. zink ignored Vulkan CPU type devices by default until 22.1.0. Nowdays it uses a priority system that automatically selects a Vulkan CPU type device if no higher priority Vulkan type device exists. You can test zink with Vulkan CPU type devices only by setting LIBGL_ALWAYS_SOFTWARE=1
(Mesa 22.1.0 and newer) or ZINK_USE_LAVAPIPE=true
(deprecated in Mesa 22.1.0).swrAVX.dll
, swrAVX2.dll
, swrSKX.dll
, swrKNL.dll
. Even though it resides outside of Mesa3D Desktop OpenGL bundle opengl32.dll
or libgallium_wgl.dll
if the latter is available, it still depends on it. This alternative desktop OpenGL software rendering driver developed by Intel is optimized for visualization software. It's available in MSVC package and since 20.1.7 in MinGW package as well. It only supports x64, x86 is officially unsupported. There are currently 4 DLLs, only one being loaded based on what the user CPU can do. You can switch to swr by setting GALLIUM_DRIVER environment variable value to swr.
osmesa.dll
. Available for both x86 and x64. This driver is used in special cases by software that is designed to use Mesa code to render without any kind of window system or operating system dependency. Since 21.0.0 only osmesa gallium remained. It supports OpenGL 3.x and newer. Since 20.0.2 osmesa integration with standalone GLLES drivers is available in both MSVC and MSYS2 Mingw-w64 packages requiring libglapi.dll
in the process.
libEGL.dll
. Mesa3D EGL library used by OpenGL ES drivers. This debuted in 21.3.0 and it's available for 32-bit and 64-bit applications in both MSVC and MSYS2 packages. It depends on desktop OpenGL bundle opengl32.dll
or libgallium_wgl.dll
if the latter is available.libGLESv1_CM.dll
and libGLESv2.dll
. OpenGL ES 1.x, 2.x and 3.x standalone drivers available for 32-bit and 64-bit applications. Since 20.0.2 they are available in both MSVC and MSYS2 Mingw-w64 packages. They depend on Mesa3D EGL library if available and desktop OpenGL bundle opengl32.dll
or libgallium_wgl.dll
if the latter is available.
lvp_icd.x86_64.json
, lvp_icd.x86.json
, vulkan_lvp.dll
. Note that some programs may ignore Vulkan CPU type devices on purpose. For information on how to deploy see usage notes.dzn_icd.x86_64.json
, dzn_icd.x86.json
, vulkan_dzn.dll
. For information on how to deploy see usage notes.radeon_icd.x86_64.json
, radeon_icd.x86.json
, libvulkan_radeon.dll
and vulkan_radeon.dll
. For information on how to deploy see usage notes.
clon12compiler.dll
(compiler), openclon12.dll
(ICD) and WinPixEventRuntime.dll
(x64 only dependency). These components introduced in 21.0.0 are finally provided by mesa-dist-win since 21.3.0 (compiler only) and 21.3.6-2 respectively. CLonD3D12 driver is available as an OpenCL ICD. For information on how to deploy see usage notes. CLonD3D12 officially requires Windows 10 v10.0.19041.488 or newer and it depends on DirectX IL for redistribution - dxil.dll
to load, which can be installed via deployment tools. CLonD3D12 is operating as wrapper returning D3D12 API calls. Due to this nature it can use D3D12 GPU acceleration if available otherwise Windows built-in WARP software rendering is used. When using WARP CLonD3D12 used to advertize CL_DEVICE_TYPE_GPU, but this changed in 23.0.0 to CL_DEVICE_TYPE_CPU, see https://github.com/microsoft/OpenCLOn12/issues/19. Some programs ignore drivers with CL_DEVICE_TYPE_CPU set on purpose. The old behavior prior to 23.0.0 can be restored since Mesa 24.0.3 by seting CLON12_WARP_IS_HARDWARE
environment variable value to 1.MesaOpenCL.dll
(ICD), OpenCL.dll
(standalone runtime), and pipe_swrast.dll
(pipe loader). The runtime can be deployed with per app deployment tool since 21.3.7 or on older versions via copy-paste along with all available pipe loaders which it depends on. While deployed, the runtime hides all other OpenCL ICDs present on the system and only lets software use Mesa3D clover as the only OpenCL driver. For information on how to deploy the ICD see usage notes.
d3d10sw.dll
. This is a drop in replacement for Microsoft WARP and unfortunately there is no clean way of deploying it.libspirv_to_dxil.dll
, spirv_to_dxil.dll
and spirv2dxil.exe
.
vaon12_drv_video.dll
. This driver was made available in 22.3.0. Just like GLonD3D12, CLonD3D12 and dozen this is a layered driver running on top of Direct3D 12 API so it can use GPU acceleration if available. Deployment instructions have been documented by Microsoft. Per application deployment tool has been updated to assist in this process.
graw.dll
, graw_null.dll
. This is a dummy gallium driver without any graphics API mainly used for testing. Available for both x86 and x64 and in full (with window system support) and headless (no window) versions. Since 20.0.2 both windowed and windowless versions are available in both MSVC and MSYS2 Mingw-w64 packages.Headers and libraries for both 32-bit and 64-bit builds are located in a separate archive called development pack.
Starting with 22.2.0 a MSVC debug info package containing debug symbols in PDB format and a MinGW asserts enabled debug optimized build package are available. MinGW debug binaries can be used as drop-in replacements for their release counterparts. With software using per application deployment, this should be seamless, but for system-wide deployment, re-deployment is necessary to switch from release to debug builds and vice-versa. For more info on MinGW debugging, see debug/mingw-start-debugging.sh
Build instructions, if you want to replicate my builds, are available here.
First choose between Mingw and MSVC package. See Differences between MSVC and MinGW packages section for details. Before extracting release package close all programs that use Mesa if any is running. After extraction you will have access to 2 deployment options, both located in the directory you installed Mesa. Both deployment utilities have a start-over mechanism so you can do all deployments you need in one session. The deployment tools only support OpenGL and OpenGL ES components of Mesa3D plus OpenCL clover standalone.
Examples on OpenGL context configuration override, switch to other driver and old applications compatibility are available here.
opencl.dll
from Windows\system32
). If you don't have system OpenCL runtime you can get it by installing Intel OpenCL CPU runtime. It works for AMD CPUs as well.libgallium_wgl.dll attrib:L
and keep Everything tool running;WARNING: Programs for which certain files have been overwritten by per application deployment tool may need re-installation/repair. Per application deployment tool detects and warns about this deployment scenario since 22.0.0.
Old applications from early 200x and older may need MESA_EXTENSION_MAX_YEAR environment variable set to avoid buffer overflows. It expects a year number as value, most commonly used being 2001. It trims the extensions list returned by Mesa3D to extensions released up to and including provided year as Mesa3D extensions list is sorted by year.
Ex: set MESA_EXTENSION_MAX_YEAR=2001
. See How to set environment variables.
With release of OpenGL 3.1 many features marked as deprecated in OpenGL 3.0 have been removed and since OpenGL 3.2 launch this OpenGL specification branch is known as OpenGL core profile. Also in OpenGL 3.3 a new branch of the OpenGL specification known as forward compatible context was introduced which removes the OpenGL 3.0 deprecated features that were not removed in OpenGL 3.1. Most proprietary drivers implemented the exemptions from these changes offered in the form of GL_ARB_compatibility extension for OpenGL 3.1 and compatibility contexts for OpenGL 3.2 and above. Due to complexity and especially lack of correct implementation tests for GL_ARB_compatibility and compatibility contexts, Mesa3D developers chose to delay work in this area until Mesa 18.1 introduced GL_ARB_compatibility support and then Mesa 21.3 bumped compatibility contexts support to OpenGL 4.5 for llvmpipe. In conclusion programs requesting OpenGL compatibility context won't get above OpenGL 3.0 for Mesa 18.0, 3.1 for Mesa 18.1 and 4.5 for Mesa 21.3 and newer. Unfortunately these kind of programs are prevalent on Windows where developers tend to avoid using context flags required by core profile. Fortunately Mesa3D provides a mechanism to override the OpenGL context requested. There are 2 environment variables that override OpenGL context configuration:
It is used to specify OpenGL context version and type. It expects a value in the following format
OpenGLMajorVersion.OpenGLMinorVersion{FC|COMPAT].
FC means a forward compatible context. COMPAT means a compatibility context for OpenGL 3.2 and newer and GL_ARB_compatibility being enabled for OpenGL 3.1. Absence of any string after version number means the Mesa3D default context type for OpenGL version specified which is as follows: deprecated features enabled for OpenGL 3.0, GL_ARB_compatibility enabled for OpenGL 3.1 since Mesa 18.1 and core profile for OpenGL 3.2 and above. Examples: 3.3FC means OpenGL 3.3 forward compatible context, 3.1COMPAT means OpenGL 3.1 with GL_ARB_compatibility , 3.2 means OpenGL 3.2 core profile. The default value for llvmpipe driver is 4.5COMPAT for Mesa>=21.3, 3.1COMPAT for Mesa>=18.1 and 3.0COMPAT for Mesa<=18.0.
A very important feature provided by this variable is the possibility to configure an incomplete OpenGL context. Programs can only request up to the highest OpenGL context with Khronos certification as complete from Mesa3D driver in use. Currently llvmpipe is certified for OpenGL 4.5 in all OpenGL profiles. Currently swr and GLonD3D12 are certified for OpenGL 3.3 in core profile / forward compatible context and 3.1 in compatibility profile. zink OpenGL support depends on underlying Vulkan driver. Since Mesa 17.3 values meant for OpenGL 4.6 are recognized.
Used to specify shading language version. Supported values are version numbers converted to integer: 110, 120, 130, 140. 150, 330, 400, 410, 420, 430, 440, 450 and 460. Value 460 is only recognized since Mesa 17.3. Value 130 for example matches GLSL 1.30. It is always a good idea to keep OpenGL context and shading language versions in sync to avoid programs confusion which may result in crashes or glitches. This can happen because most applications rely on proprietary drivers behavior of having OpenGL and GLSL versions in sync. Here is the OpenGL - GLSL correlation table. Default values for llvmpipe: 450 for Mesa 21.3, 140 for Mesa 18.1 and 130 for Mesa 18.0 if MESA_GL_VERSION_OVERRIDE is undefined or matching core profile's otherwise.
Under Windows the easiest way to set environment variables is by writing batch files. You'll most likely need to do so:
Simply open Notepad, write the batch script. When saving, end the file name with .bat or .cmd, change save as type to all files and change save location to where the application executable is located. If you have some skill with batch scripts you can change the current directory during script execution using CD command opening the possibility to save the script anywhere you want as shown in rpcs3 and GPU Caps Viewer examples. Documentation of most environment variables used by Mesa is available here. Complete examples are available here.
You can set multiple environment variables on same batch script to mix the functionality provided by Mesa3D.