pal1000 / mesa-dist-win

Pre-built Mesa3D drivers for Windows

Table of Contents

• Downloads
• Sponsorship
• Known issues
• Differences between MSVC and MinGW packages
• Mingw and MSVC Package contents
  • OpenGL and OpenGL ES common shared libraries
  • Microsoft CLonD3D12, GLonD3D12, Dozen Vulkan driver and D3D12 VA-API common dependency
  • Desktop OpenGL drivers
  • OpenGL off-screen rendering driver
  • OpenGL ES drivers and EGL library
  • Vulkan drivers
  • OpenCL drivers, compilers and backends
  • Direct3D drivers, libraries and tools
  • VA-API drivers
  • Testing library and tools
  • Development packages
  • Debug packages
• Build Mesa3D yourself
• Installation and usage
  • Usage notes
• Uninstall Mesa3D
• Legacy software compatibility
• OpenGL context configuration override
• How to set environment variables

Downloads

Mesa 24.1.2 builds with Visual Studio and MSYS2 Mingw-w64 are now available in releases section.

Sponsorship

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.

Known issues

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 drivers

This 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 ES

This 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 package

Only 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.

• 64-bit binaries in both MSVC and MinGW packages require a CPU with AVX even though they shouldn't

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.

• Programs can behave like there is no OpenGL support when using Mesa opengl32.dll since 21.0.0

This 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.

• Important notes about errors related to missing 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.

Differences between MSVC and MinGW packages

• MinGW package requires a CPU with SSSE3 with benefit of providing 3-5% performance boost with software rendering drivers;
• d3d10sw introduced in 21.2.0 is only available in MSVC package.

If you need to migrate from Mingw to MSVC binaries you just need to replace Mesa binaries folder from Mingw package with MSVC counterpart.

Mingw and MSVC Package contents

The following Mesa3D drivers and build artifacts are shipped in each release:

OpenGL and OpenGL ES common shared libraries

• GLAPI shared library. File name: 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.
• Gallium OpenGL megadriver. File name: 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.
• Mesa3D WGL runtime. File name: 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.

Microsoft CLonD3D12, GLonD3D12, Dozen Vulkan driver and D3D12 VA-API common dependency

• DirectX IL for redistribution. File name: 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.

Desktop OpenGL drivers

• llvmpipe. llvmpipe is a Desktop OpenGL software renderer intended as fallback when hardware acceleration is not possible. It can only handle very light gaming with good performance. This is the default Mesa3D desktop OpenGL driver when GLonD3D12 is either unavailable or fails to load. It's available for both x86 and x64 as part of Mesa3D Desktop OpenGL bundle 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.
• softpipe is a reference implementation of a Desktop OpenGL software renderer with no focus towards gaming performance. It's available for both x86 and x64 as part of Mesa3D Desktop OpenGL bundle opengl32.dll or libgallium_wgl.dll if the latter is available. Select it by setting environment variable GALLIUM_DRIVER=softpipe.
• GLonD3D12. It's available for both x86 and x64 in MSVC package and since 22.2.0 in MinGW package as well as part of Mesa3D Desktop OpenGL bundle 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.
• zink. This driver introduced in MinGW package in 21.0.0 and MSVC package in 21.2.0 it's available for both x86 and x64 as part of Mesa3D Desktop OpenGL bundle 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).
• swr. This driver is no longer available in Mesa 22.0 and newer. File names: 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.

OpenGL off-screen rendering driver

• osmesa. File name: 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.

OpenGL ES drivers and EGL library

• EGL library. File name: 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.
• OpenGL ES standalone drivers. File names: 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.

Vulkan drivers

• lavapipe Vulkan CPU driver is available in both MSVC and MinGW packages since 21.1.0. File names: 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.
• Microsoft dozen Vulkan driver is available since 22.1.0 in MSVC package and since 22.2.0 in MinGW package as well. This driver relies on D3D12 API to function and it can use GPU acceleration on supported systems. File names: dzn_icd.x86_64.json, dzn_icd.x86.json, vulkan_dzn.dll. For information on how to deploy see usage notes.
• Vulkan driver for AMD graphics (radv) is no longer available since 22.1.0 per @zmike suggestion as it won't work anytime soon. RADV was available in both MSVC and MinGW packages since 21.2.0. 32-bit binary of it was available since Mesa 22.0. File names: 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.

OpenCL drivers, compilers and backends

• Microsoft OpenCL stack. File names: 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 microsoft/OpenCLOn12#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.
• clover OpenCL stack has been removed from release package in 22.1.1 until Windows support is finalized as it's currently unusable. File names: 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.

Direct3D drivers, libraries and tools

• D3D10 software renderer is available in MSVC package since 21.2.0. File name: d3d10sw.dll. This is a drop in replacement for Microsoft WARP and unfortunately there is no clean way of deploying it.
• SPIR-V to DXIL tool and library are available in MSVC package since 21.0.0 and since 22.2.0 in MinGW package as well. File names: libspirv_to_dxil.dll, spirv_to_dxil.dll and spirv2dxil.exe.

VA-API drivers

• VA-API D3D12 driver. File names: 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.

Testing library and tools

• Gallium raw interface. This deprecated component has been removed in Mesa3D 22.3.0. File names: 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.
• test suite. Many executable unit tests.

Development packages

Headers and libraries for both 32-bit and 64-bit builds are located in a separate archive called development pack.

Debug packages

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 Mesa3D yourself

Build instructions, if you want to replicate my builds, are available here.

Installation and usage

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.

• A system-wide deployment tool. While intended for systems lacking hardware accelerated OpenGL support like virtual machines in cloud environments, it can also be used on any Windows system to replace the inbox software rendering OpenGL 1.1 driver extending OpenGL support for use cases where hardware accelerated OpenGL is not available like RDP connections. Due to potential issues with Virtualbox VMs running Windows it is recommended to disable 3D acceleration in such VMs if Mesa3D desktop OpenGL driver is installed inside them using the system-wide deployment tool, see #9.
• A per-application deployment tool, used to deploy Mesa3D for a single program regardless of hardware accelerated OpenGL support being present or not. Per-app deployment utility changes are persistent and are being kept across upgrades and re-installations. Per-app deployment utility helps you save storage and makes things easier as you won't have to manually copy DLLs from Mesa installation directory as it creates symbolic links to whatever Mesa drivers you opt-in to use. This behavior ensures all programs that use Mesa use the same up-to-date version. Per-app deployment utility asks for path to directory containing application executable, application executable filename (optional, it can remain blank but if specified can force some programs to use Mesa3D when they won't otherwise), if the app is 64-bit or 32-bit and the drivers you need. 32-bit applications have their names marked in Task Manager while running. Most applications will use Mesa regardless of GPU capabilities, but some applications may be smart enough to load OpenGL from system directory only. By providing the application filename, a .local file is generated in an attempt to force the application to use Mesa3D when it doesn't want to. Also, Federico Dossena's Mesainjector can be used to workaround this issue as well. Build instructions for Mesainjector.

Usage notes

• Old applications from early 200x and older may need MESA_EXTENSION_MAX_YEAR environment variable set, see legacy software compatibility section.
• Applications requiring OpenGL 3.2 or newer may need OpenGL context configuration override.

Examples on OpenGL context configuration override, switch to other driver and old applications compatibility are available here.

• The official Mesa3D documentation is available here.
• OpenCL ICDs deployment is done through registration of ICD file with system OpenCL runtime (e.g. 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.
• Deployment for Vulkan drivers is done through Vulkan runtime using ICD discovery method. Note that Vulkan runtime comes bundled with graphics drivers supporting Vulkan so manually installing it may not be necessary.

Uninstall Mesa3D

1. Run system wide deployment and perform uninstall operation if available, then exit;
2. Download and run Everything tool (any flavor should work);
3. Run per application deployment tool and leave it running;
4. In Everything tool, in text field under menu enter libgallium_wgl.dll attrib:L and keep Everything tool running;
5. For each search result in Everything tool:

• open its location in Windows Explorer via Open Path or Open File location context menu option;
• find *.local files and remove them, but only if you are certain you specified a filename during deployment to that location;
• copy location from address bar and feed it to per application deployment tool;
• send no to all deployments until you are asked to do more deployments, send yes there.

6. Repeat steps 4 and 5 using osmesa.dll and graw.dll filenames respectively the same way was done for libgallium_wgl.dll;
7. Close per application deployment and Everything tools;
8. Revert any registry changes and any environment variables that configure Vulkan runtime to use any of Mesa3D Vulkan drivers, see usage notes for clues on what potential changes you may have to revert;
9. Repeat step 8, but for OpenCL.

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.

Legacy software compatibility

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.

OpenGL context configuration override

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:

• MESA_GL_VERSION_OVERRIDE

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.

• MESA_GLSL_VERSION_OVERRIDE

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.

How to set environment variables

Under Windows the easiest way to set environment variables is by writing batch files. You'll most likely need to do so:

• for every application requiring higher OpenGL and GLSL versions than what is exposed by selected Mesa3D driver by default;
• if you want to select a non-default driver for desktop OpenGL;
• if you need to trim extensions list for old programs compatibility.

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.

mesa-dist-win's Issues

Trying to use binaries on Window Server 2016, nothing happens, binaries not started

When trying to start with Far manager it reports "Can not execute ..., The operation was cancelled by the user. Any ideas for trblshoot?

Using OSMesa on Windows

I try to use your dll for offscreen rendering under Windows with .net core.

The following code works well under Linux, but fails under Windows: no exceptions, but glReadPixels returns buffer with zeros.

public static void Main(string[] args)
{
	int w = 800;
	int h = 600;
	int length = w * h * 4;
	byte[] buffer = new byte[length];
	IntPtr pnt = Marshal.AllocHGlobal(Marshal.SizeOf(buffer[0]) * length);

	var ctx = OSMesaCreateContext(GL.GL_RGBA, IntPtr.Zero);

	try
	{
		Marshal.Copy(buffer, 0, pnt, length);

		if (!OSMesaMakeCurrent(ctx, pnt, GL.GL_UNSIGNED_BYTE, 800, 600))
		{
			Console.WriteLine("OSMesaMakeCurrent failed!");
			return;
		}

		GL.glMatrixMode(GL.GL_PROJECTION);
		GL.glLoadIdentity();
		GL.glOrtho(0.0, 1.0f, 0.0, 1.0, 0.0, 1.0);
		GL.glMatrixMode(GL.GL_MODELVIEW);
		GL.glLoadIdentity();

		GL.glBegin(GL.GL_TRIANGLES);
		GL.glColor3f(1.0f, 0.0f, 0.0f); GL.glVertex2f(0.0f, 0.0f);
		GL.glColor3f(0.0f, 1.0f, 0.0f); GL.glVertex2f(0.5f, 1.0f);
		GL.glColor3f(0.0f, 0.0f, 1.0f); GL.glVertex2f(1.0f, 0.0f);
		GL.glEnd();

		GL.glReadPixels(0, 0, w, h, GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, pnt);

		Marshal.Copy(pnt, buffer, 0, length);

		using (Image<Rgba32> image = Image.LoadPixelData<Rgba32>(buffer, w, h))
		{
			image.Save("test.bmp", new BmpEncoder());
		}
	}
	finally
	{
		OSMesaDestroyContext(ctx);
		Marshal.FreeHGlobal(pnt);				
	}

	Console.WriteLine("OK");
}

[DllImport("osmesa-gallium")]
public static extern IntPtr OSMesaCreateContext(uint format, IntPtr sharelist);
[DllImport("osmesa-gallium")]
public static extern IntPtr OSMesaCreateContextExt(uint format, int depthBits, int stencilBits, int accumBits, IntPtr sharelist);
[DllImport("osmesa-gallium")]
public static extern bool OSMesaMakeCurrent(IntPtr hdc, IntPtr buffer, uint type, int width, int height);
[DllImport("osmesa-gallium")]
public static extern void OSMesaDestroyContext(IntPtr hdc);

I put opengl32.dll and osmesa-gallium.dll into my bin folder.

I would be grateful if you could tell any suggestions what I could miss

GLSL 4.20 is not supported.

NV_depth_buffer_float: not supported
[06:30:28] Error/Warning in vertex shader:
[06:30:28] 0:1(10): error: GLSL 4.00 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.00 ES, and 3.00 ES

can you help please with this error ?

OpenGL ES support

Hello

I have OpenGL Version 2.1 and I want run Blender 2.80 that support OpenGL 3.3 minimum, so I downloaded Mesa 3d for windows and it requires ( libglpi.dll ) please I want it for Important ?

Thanks

Support for OpenGL ES 3.1

Hi, I'm trying to run Android Emulators on my Windows 10 PC which has an old GPU that doesn't support newer versions of OpenGL and was wondering if this driver can help with this. I understand that performance won't be great but I'm just trying to test some stuff out.

I get the follow error message when loading some games and was wondering if OpenGL ES 3.1 is supported, thanks a lot for any feedback in advance!

[Project Unrelated] WineD3D Build?

Recently read on Federico Dossena's page that he's busy lately and so I think WineD3D builds are not updated.
I'm not sure wined3d ver 6 released (it's rc6 on fdossena.org)
Nevertheless could you create a build of wined3d for windows?

P.S. sorry I didn't know how else to contact you..
P.P.S. Much thanks for both your swiftshader and mesa build!

MESA 21 OpenGL-DXIL: forced negative LoD Bias?

Why the image presented to the output (monitor) seems like processed by a sharpening filter?
Mipmap LoD management issues?

PNG (screenshot taken via STAMP button, load the FULL RESOLUTION version ) -> https://ibb.co/XSTFsdG

No problem with LLVMPipe ! Output is regular!

Vallium (Mesa Vulkan CPU backend)

Hi,
seems Vallium was merged into Mesa last month:
https://www.phoronix.com/scan.php?page=news_item&px=Mesa-VALLIUM-Merged
currently it's in Mesa master (so should be in 20.3)..
don't know current status but might be very immature at this point..
anyway, any interest to also ship Vallium Vulkan CPU driver in your Win Mesa builds?

thanks..

Add file infos to dlls

Currently the fileinfos are empty.
It would be nice to have at lest the mesa version somewhere in the fileinfos so i can identify what version of mesa i am currently using.

Mesa 20.1 RC1 binaries request

Simple request: can we have the 20.1 RC1 builds to test it?

Thanks!

Antivirus claims release files contain Trojan:Win32/CryptInject!ml

Hello,
Any attempt to download recent msvc release files are blocked by antivirus claiming the Trojan:Win32/Cryptinject!ml
The mingw release seem to work fine

Any Direct3D implementation on top of these Mesa drivers?

Installing your Mesa drivers in my Virtualbox VMs has greatly improved graphics compatibility. However, there's one application (Revit 2019) that won't use Mesa if Direct3D is not detected. It doesn't detect D3D, so it defaults to its own software renderer, but something strange happens because that renderer has become really slow (about 30 seconds per frame!!) after installing the Mesa drivers. I checked that all kinds of hardware acceleration are disabled for this VM. It runs Windows 7 64bit, latest service pack, and Virtualbox is 5.2.18.

Somehow, I have the feeling that if there was any Direct3D implementation that could be used on top of the Mesa drivers, then it would work fine... Is there any such implementation? Thanks!

Mesa windows doesn't work with yuzu

Hi... I'm trying to get yuzu (switch emulator) works with mesa and I created a bat file with MESA_GL_VERSION_OVERRIDE=4.5COMPAT

Yuzu runs but it doesn't display anything, I can only hear the sound... I have black screen... Is this a bug? I have tried old version of mesa too, but it has the same problem D: Is there anyway to fix it?

Usage with Android emulator on Azure Windows 10 virtual machine?

After downloading mesa3d-19.1.3-release-mingw.exe-> unzipping -> Runningsystemwidedeploy.cmd and selecting 6. Update system-wide deployment. The drivers on my Azure Windows 10 vm don't appear to be updated. Running Android emulator I get the following message:

I was expecting the Microsoft Basic Render Driver to change?

Interested in shipping CLonD3D12 and GLonD3D12 on your dist?

Hi,
just forgot to ask about your interest on this announcement of CL and GL over D3D12:
"https://www.collabora.com/news-and-blog/news-and-events/introducing-opencl-and-opengl-on-directx.html"
no hurry, just asking.. as right now isn't even merged on mesa master branch.. but that's the plan eventually.. seems right now implementation is changing fast : https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests

really just opening issue so I get notified of eventual news on this .. :-)
thanks..

Support for unattended installation

I think being able to install via scripts would be a very useful feature. As it is now it is not possible to use the deploy scripts in provisioning systems. I am currently working with Github runners. As these are VMs created on-demand they need setting up at each run via scripts.
I did try and modify the systemwidedeploy.cmd to accept an argument (1 - 6) but it was getting very complicated bypassing the "pauses" and "goto deploy"
It would be great if you could add a script that accepts an argument instead of the menu based install.

ARM64 releases?

Hi,
now that one use case of CLonD3D12 and GLonD3D12 is clear:
https://devblogs.microsoft.com/directx/directx-heart-linux/
seems other use case Microsoft is interested is for Windows on ARM64 as this version doesn't have OpenGL/OpenCL support..
see:
https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/69
seems they are testing support for Photoshop OpenCL kernels on CLonD3D12 and this maybe useful jointly with also upcoming Windows ARM64 x64 emulation support..
anyway all that intro was to ask also how difficult would be to ship you mesa OpenGL software rasterizers for ARM64? SWR makes no sense but hope llvmpipe is Neon accelerated.. as Mesa supports Linux ARM64..
note that I haven't yet any Win ARM64 machine so just curious to ask..
thanks..

Build script - MSVC build: Segmentation fault with Windows 10 April 2019 Update when Python launcher is not installed

Root cause: %LOCALAPPDATA%\Microsoft\WindowsApps is in PATH and %LOCALAPPDATA%\Microsoft\WindowsApps\python.exe is provided as a convenience shortcut to Python 3.x UWP version.

Cannot create newer OpenGL contexts.

Using Mesa, I am unable to create an OpenGL context past version 3.3. Any later version gives the error: "WGL: Failed to create OpenGL context". Even though the normal driver supports OpenGL 4.3, using Mesa I can only use up to version 3.3. The OpenGL version is given as "OpenGL version 3.1 Mesa 19.0.2". Isn't Mesa 19.0.2 supposed to implement up to OpenGL 4.5?

Using glewinfo, it shows that OpenGL 4.1-4.5 are missing (although the extensions from those versions are not). However, I am still unable to create an OpenGL 4.6 context, which is marked as "OK".

Virustotal results

Guys, any idea why virustotal has some alerts?
https://www.virustotal.com/gui/file/c170e5b02191528330b8dbf42e2a19aaab68ad4700872a2021896c385b6e85fb/detection

SWR Drivers result in a black screen.

Using the SWR drivers (GALLIUM_DRIVER=swr) results in a completely black screen. The code:

• Runs natively
• Works with llvmpipe and softpipe
• Reports no errors with glGetError()
• Does not contain function pointer for OpenGL functions which are NULL
• Has MESA_GL_VERSION_OVERRIDE and MESA_GLSL_VERION_OVERRIDE

Why do these not work?

Windows Defender Issue

Hi,

On Windows 10, Windows Defender complains about finding 3 trojans inside the latest release package;

Can you check and clean if possible?

Zink on Windows+AMD/Nvidia Vulkan Drivers

Using "mesa3d-21.0.0-rc5-release-msvc.7z"

Gallium=llvmpipe -> perfectly working
Gallium=D3D12 -> perfectly working
Gallium=zink -> ?!?!?!?!

mesa is slow on windows to compared to linux

am using pre compiled modules and its slow any ideas how to fix this

Automatic build environment information dumping

Up until now I was maintaining build environment information in buildenvconf.md. This however has some drawbacks:

• it is a manual process;
• it only covers MSVC build, MSYS2 Mingw isn't covered.

To automate this process it is necessary to acquire version information for each dependency including optional ones and dump all this information to a file for MSVC build and another for Mingw build.

Common dependencies

• Windows;
• Resource Hacker;
• 7-zip
• Git for Windows
• Build commands and notes

MSYS2 build dependencies

• a dump of "pacman -Q" is enough.

MSVC build dependencies

• Visual Studio
• Windows SDK;
• Python and its required packages
• LLVM
• Ninja
• CMake
• winflexbison package
• flex
• Bison

Qt5 application crashes when using MESA

Hi!

I was hoping to be able to run a program called Topaz Labs JPEG to RAW AI on a VMware server using software/CPU mode. It's a Qt5 application. The VMware server is running Windows Server 2008 R2.

I downloaded and installed the trial. When I try to run the program, it crashes instantly with this:

Faulting application name: Topaz JPEG to RAW AI.exe, version: 0.0.0.0, time stamp: 0x5c4f4ade
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0000000000000000
Faulting process id: 0x16c0
Faulting application start time: 0x01d5e2c1e27805ff
Faulting application path: C:\Program Files\Topaz Labs\Topaz JPEG to RAW AI\Topaz JPEG to RAW AI.exe
Faulting module path: unknown
Report Id: 2167a7cf-4eb5-11ea-a2a8-0050560b8935

I can see in the installation directory there is an opengl32sw.dll file. Not sure if this is MESA based or what, but I tried renaming it to opengl32.dll. The program looks like it gets a little farther but it still crashes, this time with the following:

Faulting application name: Topaz JPEG to RAW AI.exe, version: 0.0.0.0, time stamp: 0x5c4f4ade
Faulting module name: Qt5Gui.dll, version: 5.12.0.0, time stamp: 0x5c0514b1
Exception code: 0xc0000005
Fault offset: 0x00000000002f1310
Faulting process id: 0x938
Faulting application start time: 0x01d5e2c2041f97ef
Faulting application path: C:\Program Files\Topaz Labs\Topaz JPEG to RAW AI\Topaz JPEG to RAW AI.exe
Faulting module path: C:\Program Files\Topaz Labs\Topaz JPEG to RAW AI\Qt5Gui.dll
Report Id: 42dcdf1f-4eb5-11ea-a2a8-0050560b8935

Finally, I tried copying in opengl32.dll from the latest 64 bit MESA mingw release into the application directory. This also didn't work; I get the same crash as above (0xc0000005 in Qt5Gui.dll).

(I also tried the MSVC release; it didn't have a different result.)

The program appears to have a Windows registry key for software mode:

[HKEY_CURRENT_USER\Software\Topaz Labs\Topaz JPEG to RAW AI\appMain]
"j2r_gpuOrCpu"=dword:00000001

(I assume 1 is for CPU; it's set to 0 by default.)

That also didn't have any effect.

Again, I did verify with Dependency Walker that the MESA opengl32.dll was loading from the application directory. It was.

From what I've researched online, both JPEG to RAW as well as Qt5 should support software mode. I have so far had a lot of success using software that uses OpenGL on a VMware server by using MESA.

Have you heard of anything like this before and know of a way to fix this?

My virtual machine is running Windows Server 2008 R2 (which is Windows 7 x64 based).

Meson build support

To add Meson build support to the build script the following tasks must be completed:

Preparation phase

• Ensure everything is loaded and unloaded from PATH correctly;
• Split the build script into modules to handle growth triggered by this new feature support.

Python

• Recognize the Python version (py2/3 awareness);
• Extend py2/3 awareness with Python launcher support;
• Research what modules are needed for py3 / meson build and make the appropriate changes.

Mesa3D

• Support build with Meson and MsBuild if applicable;
• Support build with Meson and Ninja if applicable;
• LLVM Meson binary wrap support (required for llvmpipe and SWR);
• Retain current control over build targets or options.

Check new dependencies

• pkg-config and if needed libwinpthreads.

Finale

• Test for regressions and fix bugs.

installing opengl32.dll in VirtualBox disables admin mode

I've installed mesa-18.1.0.600-1-sfx.exe using option 1 in 'systemwidedeploy.cmd' in VirtualBox 5.2.12 with guest Win10 Pro version 1803. If I try to start a command window using 'Run as Administrator', a error dialog pops up with "File System error (-1073741189)." Other attempts to perform actions requiring admin privileges result in the same error. I don't see this problem with VMware running a similar guest. I haven't found any explanation for what the error code means, nor any similar reports.

If this isn't the best forum to report this problem, please let me know. Thanks.

Request for a Mesa 20.0rc1 build for testing new SWR tesselation support..

Hi,
I know isn't yet released but asking already in case I forget later.. mainly motivated on testing tesselation apps like Tessmark (requires env vars MESA_GL_VERSION_OVERRIDE=4.1 & MESA_GLSL_VERSION_OVERRIDE=410 to start_tessmark_windowed_1024x640)..

https://cgit.freedesktop.org/mesa/mesa/commit/?id=f09c466732e4a5b648d7503787777c926dd93c29

binary package with .lib and headers

Hi,

Would it be possible to make an installer that includes also the libs and the headers? I'm trying to port a unix program that uses the GLX API and need them while building that other program.

Thanks

Uninstall in VirtualBox guest?

Hi!

Just a quick question: I'm reading that when you install these drivers, you cannot enable again the 3D acceleration from VirtualBox. That's fine for me (in fact I'm going to use mesa-dist-win because the 3D acceleration in VirtualBox is not good enough for the apps I use), but, in case I need to enable 3D acceleration again in the future, how should I proceed? Can I uninstall mesa-dist-win, enable 3D acceleration, and later reinstall mesa-dist-win again if I wish to use Mesa again?

Thanks!

20.3 RC build release?

Please! 👍

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.3-RC1-Released&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Phoronix+%28Phoronix%29

Missing DXIL binaries

I can't seem to find spirv_to_dxil executable and/or libspirv_to_dxil in the release packages.

In the source tree it would be these build targets:
https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/microsoft/spirv_to_dxil/meson.build

Do you build only drivers and this is intentional or can I possibly ask for these two to be added as well?

Missing files in deploy

I am trying to use mesa-dist-win on github CI runners. To do so I need to automate the deploy script.
I have found that in the systemwidedeploy.cmd script it tries to copy some files that do not exist in the package.
In the osmesa section, it has
@if "%deploychoice%"=="3" set osmesatype=gallium @if "%deploychoice%"=="4" set osmesatype=swrast @IF /I %PROCESSOR_ARCHITECTURE%==X86 copy "%mesaloc%\x86\osmesa-%osmesatype%\osmesa.dll" "%windir%\System32" @IF /I %PROCESSOR_ARCHITECTURE%==AMD64 copy "%mesaloc%\x86\osmesa-%osmesatype%\osmesa.dll" "%windir%\SysWOW64" @IF /I %PROCESSOR_ARCHITECTURE%==AMD64 copy "%mesaloc%\x64\osmesa-%osmesatype%\osmesa.dll" "%windir%\System32"

But in the package, the directories osmesa-galium and osmesa-swrast do not exist. If they did exist these lines would overwrite the osmesa.dll that had already been copied.

SWR AVX512 support

Phoronix found some difficulties to build AVX512 support so just asking? Perhaps fixed in 17.3 master branch?

Win32/Wacatac.B!ml Trojan in x86\sanitycheckc.exe

Details are in the heading. Might worth a check... Different malware is reported in different versions. i.e. mesa3d-20.3.4-release reports Trojan:Script/Conteban.A!ml.

How to disable AVX instruction set in opengl32.dll compilation

I am getting illegal instruction when I trying to use opengl32.gll
From depends_x64
00:00:21.282: Second chance exception 0xC000001D (Illegal Instruction) occurred in "%DIR%\OPENGL32.DLL" at address 0x00007FF975EDB0E3 by thread 1.

Here I saw about AVX instruction set:
https://www.gamedev.net/forums/topic/648813-illegal-instruction-possible-causes/

How can I change the instruction set in opengl32.dll compilation? (maybe removing the AVX instruction set)

Rendering a completely black screen

Hello!

This is probably a user related issue (me) but I couldn't find another way to contact you and ask about the issue. I am running Windows 10 and I'm using AMD R9 280 GPU, the app I want to run is Cemu, which is an emulator of the Wii U.

Since AMD OpenGL drivers are not that good, I wanted to try the Mesa drivers and found this thread: https://www.opengl.org/discussion_boards/showthread.php/199121-Mesa3d-installing-for-Windows-10/page3

I downloaded the mesa-18.2.6-release-sfx.exe, ran it, then I ran the perappdeploy.cmd, and provided the info for the folder of cemu.exe. Now Cemu runs using mesa it seems (At least it says Generic GPU driver, instead of AMD GPU as it normally does), but the screen is completely black. I have tried a couple of different settings in the perappdeploy.cmd, but the result is the same. Have I missed something fundemental? Anything else that I might be doing wrong?

I am quite convinced that there is a large community out there that would very much appreciate it, if this solution would work.

Many thanks in advance!

POCL

I post the request as an "issue" 'cause it's the only way to contact pal1000 through github :-D

Man, can you do the same (windows binaries) for POCL now @1.0? https://github.com/pocl/pocl

Question: it's easy to include Zink driver in your dist?

Hi,
just forgot Zink got merged in Mesa some months ago and just curious if possible to build this driver also in your Mesa distribution.. as you know is a OpenGL 3.x driver that routes calls to underlying Vulkan driver on the system or that's the idea at least.. don't know if requires some specific Win patches or can build easily..
as said just a question, not a real need, and no pressure to integrate in case you aren't interested or it's currently unbuildable on Windows..
thanks..

How to uninstall Mesa3D from Win10?

I just upgraded my pc with a new mobo, RAM and CPU. The CPU is Ryzen 5 2400G with Vega 11 onboard. Thing is, my monitor is a VGA D-sub, which is not supported by my mobo (Gigabyte GA-A320M-H), so when I install video drivers, the screen goes to noise after 2 seconds, then blacking it and it starts again. I tried to install Mesa3D instead and wasn't happy with the results and decided to remove it. Question is - how do i remove it?

Request for master build (20.2dev) with MSAA LLVMpipe support..

Hi,
don't know if it's much to ask for, but anyway interested to try new LLVMpipe MSAA 4x support merged recently along with three new exts supported:
(mesamatrix)
2 days | llvmpipe: enable ARB_sample_shading
2 days | llvmpipe: enable GL_ARB_shader_texture_image_samples
2 days | llvmpipe: simple texture barrier implementation. (GL_ARB_texture_barrier)

Also few ours ago "wgl: add MSAA support" was merged fixing/adding that support to Windows..
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4926

even Phoronix writed an article:
https://www.phoronix.com/scan.php?page=news_item&px=LLVMpipe-4x-MSAA-Bits

thanks anyway for your work!

win10 defender detects Vigorf.A trojan in msvc release

Publish prebuilts as archive, not as self-extracting exe

Makes it easier to integrate in automated pipelines like e.g. VCPKG and looks less "shady" than executing an exe. Developer mostly know archives and how to extract them.

Mesa3D - NVIDIA CG fp40 vp40

Not an issue related to your installer, works fine, but I was wondering if you could take a look at this, not sure on how to contact you besides here.

https://www.opengl.org/discussion_boards/showthread.php/199760-Mesa3D-NVIDIA-CG-and-OpenGL-profiles-vp40-fp40

Cheers!

A dead end with the Chocolatey sketchup package?

I'm facing the unsupported Hardware acceleration error message that your great software responds to.
I installed Sketchup 2017 as a Chocolatey package.

2 remarks :

• This 2017 release of SketchUp is the last, installable, free version of SketchUp.
• the Chocolatey page mentions the Hardware requirement : it requires a 3D class video card with 1GB of memory or higher and hardware acceleration which my old Dell Latitude laptop does not have.

Here is the dedicated page
Once all the information required by mesa3d was filled in, I launched sketup.exe
But nothing happens anymore. So I sadly had to uninstall the package.

I don't know if the blocking is on the side of this old 2017 Sketchup version or if we I should rather study the specificity of the Chocolatey package.

Any idea ?

OpenCL support through clover over llvmpipe

Add @donizettilorenzo to conversation as he showed interest in this topic as #5.

Recently Mesa3D landed clover state tracker support to llvmpipe driver which should provide an OpenCL CPU runtime similar to POCL that hopefully builds on Windows.

Roadmap

• Attempt clover build in standalone mode then test it with GPU Caps Viewer if builds successfully (fails: 1)
• Decide on a pre-built OpenCL ICD loader. Tested NVIDIA build and it worked just fine.
• Build in ICD mode then register and test it with GPU Caps Viewer if builds successfully.
• Update per app deployment tool to support OpenCL standalone install mode.
• Update system wide deployment tool to support OpenCL ICD install mode by complying with this spec.

Bonus

• Fake advertise CL GPU support on Microsoft Basic Display Adapter.

Need a mechanism to collect debug symbols

@TheLastRar commented in #50.

With MinGW release and the hotfix my OpenGL application starts and works setting Gallium=zink
What hotfix did you do?

I'm trying to get the MinGW release to work, but my program just hangs (and then crashes a little later)
This happens even when I'm not settings Gallium environment variables.

Just a thanks message!

Sorry for writing an issue but i just wanted to thank you!!! This was very useful! I had a very hard time compiling Mesa.

Once more, Thank You!

MSYS2 Mingw support

MSYS2 Mingw is slightly faster than MSVC as it benefits from SSSE3 optimization via -march=core2 compiler flag which lacks equivalent in MSVC build and even further optimizations can be applied by changing march value to newer CPU generation. Historically @Alexpux didn't post regular updates to MSYS2 Mingw builds of Mesa so I feel I should tackle this as well. Reverse engineering his build doesn't appear to be very hard.

Tasks list

• Support locating and loading of MINGW64 and MINGW32 environments;
• Research necessary packages and patches and implement their management, use pre-built LLVM (info available here : https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-mesa);
• Update Mesa3D build to to use toolchain=mingw option;
• Update distribution creation to support linux .a libraries;
• pass necessary compiler and linker flags.

Note: Deployment tools work unchanged.

Optional

• Self made LLVM build;
• swr build (needs upstream fixes).

Longer term

• Meson build support.