View source for MesaLlvmpipe

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

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 2017. You only need components from within Desktop Development with C++ category. Beside default selected components MFC, ATL and a Windows SDK is required. Latest Windows 10 SDK is highly recommended. You may opt-out in this exact order of CMake Tools and Windows 10 SDK in Visual Studio installer and manually install standalone version of Windows 10 SDK instead as it is sometimes newer. If you want to use standalone Windows 10 SDK make sure you install Windows SDK for Desktop C++ x86 and amd64 apps components.
* 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))
* [https://github.com/mhammond/pywin32/releases pywin32 for Python] (required by Mesa Scons and Visual Studio native build). The installer will work just fine despite a bug. Mesa will build successfully despite it, but for the sake of true success you have to open a Command Prompt as admin window, browse to the folder holding pywin32 installer using CD command and run it from there.
* Update setuptools bundled with Python (not required but is recommended):
<pre>
pip install -U setuptools
</pre>
* install wheel for python (required for Python 2.7.15, optional for Python 2.7.14 - install it only if setuptools is obsolete.)
<pre>
pip install -U wheel
</pre>
* scons 3.0.1 (the regular Windows installer from scons.org is fine). Can also be installed via Pypi using '''pip install -U scons''' if setuptools is updated or wheel is installed. If both setuptools is obsolete and wheel is not installed you should use the windows installer. '''pip install --egg scons''' which is the only Pypi method to install Scons in this case is messy and most likely you won't be able to update Scons in the future.
* The Mako templating engine: '''pip install -U mako'''
* 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>
* 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.

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

Step 1: Get and build LLVM.

Since Mesa 17.2.2 LLVM 5.0 is supported.
<pre>
wget http://llvm.org/releases/5.0.0/llvm-5.0.0.src.tar.xz
</pre>
May need 7zip or a win32 build of xz-utils to decompress it: http://tukaani.org/xz/

Configure it:

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

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:

<pre>
msbuild /p:Configuration=Release INSTALL.vcxproj
</pre>

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

<pre>
wget ftp://ftp.freedesktop.org/pub/mesa/mesa-17.2.2.tar.xz
</pre>

Build it:

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

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:

17.1.x and older
<pre>
GL_VENDOR: VMware, Inc.
GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)
GL_VERSION: 3.0 Mesa 11.2.2
</pre>
17.2.x and newer
<pre>
GL_VENDOR: VMware, Inc.
GL_RENDERER: llvmpipe (LLVM 5.0, 256 bits)
GL_VERSION: 3.0 Mesa 17.2.2
</pre>

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.