MesaLlvmpipe

How to build Mesa for software rendering with llvmpipe on Windows with Visual Studio 2015

These are the official instructions for building opengl32sw.dll which is shipped with the binary Qt packages and are also available at http://download.qt.io/development_releases/prebuilt/llvmpipe/windows/

Based on http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows but without any special requirements for cross-compiling or tools and with some additional patches.

Note that the pre-compiled binaries provided on that wiki page are not able to run many Quick applications due to problems in the LLVM optimization passes. Hence we make our own build. This also gives us the ability to debug and fix/enhance things, if needed.

Prerequisites:

• Visual Studio 2015 (Update 3). Visual Studio 2017 can also be used but you have to workaround Mesa/Scons shared bug 100202 and patch LLVM 3.9.1 code in lib\DebugInfo\PDB\DIA\DIASession.cpp line 61 or if building Mesa 17.1 use LLVM 4.0. All the steps below assume you are in a Visual Studio command prompt (32 or 64 bit, depending on the target DLL you want, but note that some of the configuration shown below may need adjustments accordingly)
• Python 2.7 (from python.org, Python 3 is not supported by Scons, also not the ActiveState one, due to issues with installing libxml2 on the latter (update: not sure if this issue is still valid, the AS one may work now too, but not tested))
• scons 2.5.1 (the regular Windows installer from scons.org is fine) - Note that 2.5.0 is not compatible with Mesa as it shipped incomplete according to 2.5.1 release notes:

https://bitbucket.org/scons/scons/raw/8d7fac5a5e9c9a1de4b81769c7c8c0032c82a9aa/src/CHANGES.txt

• cmake (Windows installer from the cmake website)
• flex and bison
• m4 (only if cross-compiling, not recommended).

Note that Bison 2.7 seems to crash. Use 3.0 or the old 2.4.1 instead (available from gnuwin32). The mesa scons script expects winflexbison from here: https://sourceforge.net/projects/winflexbison/ rather then the one from Msys2. You might get Msys2 flavor working by renaming the executables adding win_ at the begging of their names (untested). M4 is available at Msys2 sourceforge repository (Msys2 tools, there is also a Mingw tools section, but we don't need anything from there). Make sure all tools are available in the PATH.

Then install python packages:

• libxml2 for Python (only if building Mesa with Scons and a crosscompiler like GCC on a Msys2/Mingw/Cygwin environment, not recommended, scenario not covered in this wiki, it is known that 32-bit mesa resulted through this build method won't work, any application using it will crash see https://github.com/Alexpux/MINGW-packages/issues/2089). Get the wheel file libxml2_python-2.9.3-cp27-none-ARCH.whl from http://www.lfd.uci.edu/~gohlke/pythonlibs and run pip install <file>
• pywin32 for Python (needed for Mesa Scons and Visual Studio native build, recommended, get it from sourceforge, the installer will work just fine)
• The Mako templating engine: pip install mako

Step 1: Get and build LLVM If you still target Mesa 17.0.x, you are capped at LLVM 3.9.1. It is known that Mesa 17.0 can't link LLVM 4.0 due to missing symbols see Mesa bug 100201. LLVM 4,0

wget http://llvm.org/releases/4.0.0/llvm-4.0.0.src.tar.xz

LLVM 3.9.1

wget http://llvm.org/releases/3.9.1/llvm-3.9.1.src.tar.xz

May need 7zip or a win32 build of xz-utils to decompress it: http://tukaani.org/xz/

Configure it:

cmake -G "Visual Studio 14 Win64" -DLLVM_USE_CRT_RELEASE=MT -DLLVM_USE_CRT_DEBUG=MTd -DCMAKE_INSTALL_PREFIX=c:/work/mesa/llvm/bin .

This means the static libraries and other tools will be installed to c:\work\mesa\llvm\bin Leave out Win64 from the generator name when making 32-bit builds and having the x86 developer command prompt open.

Build it:

msbuild /p:Configuration=Release INSTALL.vcxproj

Step 2: Get and build Mesa 11.2.2 (or newer)

wget ftp://ftp.freedesktop.org/pub/mesa/11.2.2/mesa-11.2.2.tar.xz

Build it:

set LLVM=c:/work/mesa/llvm/bin
scons build=release platform=windows machine=x86_64 libgl-gdi

Change to build=debug to get a debug build, but note that both LLVM and Mesa must be built in the same configuration. Change to machine=x86 to generate 32-bit builds.

The result is an opengl32.dll in build\windows-x86[_64][-debug]\gallium\targets\libgl-gdi. This provides a WGL and desktop OpenGL 3.0 implementation and is a drop-in replacement for the system's own opengl32.dll. There are two ways to use it: Copy it to a Qt executable's directory (since that is searched first when looking for DLLs) and launch the app. - OR - The modern way: ship it as opengl32sw.dll and set QT_OPENGL=software (or setAttribute(AA_UseSoftwareOpenGL in main()) to force it (this needs a -opengl dynamic build of Qt of course).

Identification:

GL_VENDOR: VMware, Inc.
GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)
GL_VERSION: 3.0 Mesa 11.2.2

Additional notes:

• Using opengl32sw.dll will trigger using a non-threaded render loop in Qt Quick, similarly to ANGLE. This is intentional. However, apps may want to set QSG_RENDER_LOOP=basic to prevent animations from running too fast! The default on Windows is "windows", which is not ideal for a non-throttled software rasterizer.
• The output is not really vsynced so native and naive OpenGL apps will run at random speed (although it is throttled to some extent). For Quick apps this is less of an issue, at least when the 'basic' render loop is in use.
• Run with QT_LOGGING_RULES=qt.qpa.gl=true and QSG_INFO=1 to verify what is going on.