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.
- Visual Studio 2015 (Update 3). Visual Studio 2017 is supported since Mesa 17.2.3 which workarounds Scons 3.0.0 bug with print statements which in turn is the first version of Scons to support Visual Studio 2017. To use Visual Studio 2017 with Mesa 17.2.2 and older you have to workaround Mesa/Scons shared bug 100202 or use Scons 3.0.0 which raise problems as well, read below. 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:
Scons 3.0.0 can also be used, but you have to patch Mesa code to workaround a regression in Scons which broke print statements support. Patch is here (requires Git version control to apply): https://patchwork.freedesktop.org/patch/177680/
This patch landed in Mesa 17.2.3.
- 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.
Since Mesa 17.2.2 LLVM 5.0 is supported.
May need 7zip or a win32 build of xz-utils to decompress it: http://tukaani.org/xz/
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.
msbuild /p:Configuration=Release INSTALL.vcxproj
Step 2: Get and build Mesa 17.2.2 (or newer)
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).
17.1.x and older
GL_VENDOR: VMware, Inc. GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits) GL_VERSION: 3.0 Mesa 11.2.2
17.2.x and newer
GL_VENDOR: VMware, Inc. GL_RENDERER: llvmpipe (LLVM 5.0, 256 bits) GL_VERSION: 3.0 Mesa 17.2.2
- 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.