LLVMPIPE -- a fork of softpipe that employs LLVM for code generation.
-Status
-======
-
-Done so far is:
+Requirements
+============
- - the whole fragment pipeline is code generated in a single function
-
- - input interpolation
-
- - depth testing
+ - A x86 or amd64 processor. 64bit mode is preferred.
- - texture sampling (not all state/formats are supported)
+ Support for sse2 is strongly encouraged. Support for ssse3, and sse4.1 will
+ yield the most efficient code. The less features the CPU has the more
+ likely is that you ran into underperforming, buggy, or incomplete code.
- - fragment shader TGSI translation
- - same level of support as the TGSI SSE2 exec machine, with the exception
- we don't fallback to TGSI interpretation when an unsupported opcode is
- found, but just ignore it
- - done in SoA layout
- - input interpolation also code generated
+ See /proc/cpuinfo to know what your CPU supports.
- - alpha testing
+ - LLVM 2.6 (or later)
- - blend (including logic ops)
- - both in SoA and AoS layouts, but only the former used for now
+ For Linux, on a recent Debian based distribution do:
- - code is generic
- - intermediates can be vectors of floats, ubytes, fixed point, etc, and of
- any width and length
- - not all operations are implemented for these types yet though
-
-Most mesa/progs/demos/* work.
-
-To do (probably by this order):
-
- - code generate stipple and stencil testing
-
- - translate the remaining bits of texture sampling state
-
- - translate TGSI control flow instructions, and all other remaining opcodes
-
- - integrate with the draw module for VS code generation
+ aptitude install llvm-dev
- - code generate the triangle setup and rasterization
+ For Windows download pre-built MSVC 9.0 or MinGW binaries from
+ http://people.freedesktop.org/~jrfonseca/llvm/ and set the LLVM environment
+ variable to the extracted path.
+ For MSVC there are two set of binaries: llvm-x.x-msvc32mt.7z and
+ llvm-x.x-msvc32mtd.7z .
-Requirements
-============
+ You have to set the LLVM=/path/to/llvm-x.x-msvc32mtd env var when passing
+ debug=yes to scons, and LLVM=/path/to/llvm-x.x-msvc32mt when building with
+ debug=no. This is necessary as LLVM builds as static library so the chosen
+ MS CRT must match.
- - Linux
-
- - A x86 or amd64 processor with support for sse2, sse3, and sse4.1 SIMD
- instructions. This is necessary because we emit several SSE intrinsics for
- convenience. See /proc/cpuinfo to know what your CPU supports.
-
- - LLVM 2.5 or greater. LLVM 2.6 is preferred.
-
- On Debian based distributions do:
-
- aptitude install llvm-dev
+ The version of LLVM from SVN ("2.7svn") from mid-March 2010 is pretty
+ stable and has some features not in version 2.6.
- There is a typo in one of the llvm 2.5 headers, that may cause compilation
- errors. To fix it apply the change:
-
- --- /usr/include/llvm-c/Core.h.orig 2009-08-10 15:38:54.000000000 +0100
- +++ /usr/include/llvm-c/Core.h 2009-08-10 15:38:25.000000000 +0100
- @@ -831,7 +831,7 @@
- template<typename T>
- inline T **unwrap(LLVMValueRef *Vals, unsigned Length) {
- #if DEBUG
- - for (LLVMValueRef *I = Vals, E = Vals + Length; I != E; ++I)
- + for (LLVMValueRef *I = Vals, *E = Vals + Length; I != E; ++I)
- cast<T>(*I);
- #endif
- return reinterpret_cast<T**>(Vals);
-
- scons (optional)
- - udis86, http://udis86.sourceforge.net/ (optional):
+ - udis86, http://udis86.sourceforge.net/ (optional). My personal repository
+ supports more opcodes which haven't been merged upstream yet:
- git clone git://udis86.git.sourceforge.net/gitroot/udis86/udis86
+ git clone git://anongit.freedesktop.org/~jrfonseca/udis86
cd udis86
./autogen.sh
./configure --with-pic
Building
========
-To build everything invoke scons as:
+To build everything on Linux invoke scons as:
- scons debug=yes statetrackers=mesa drivers=llvmpipe winsys=xlib dri=false -k
+ scons build=debug libgl-xlib
Alternatively, you can build it with GNU make, if you prefer, by invoking it as
but the rest of these instructions assume that scons is used.
+For windows is everything the except except the winsys:
+
+ scons build=debug libgl-gdi
Using
=====
-Building will create a drop-in alternative for libGL.so. To use it set the
-environment variables:
-
- export LD_LIBRARY_PATH=$PWD/build/linux-x86_64-debug/lib:$LD_LIBRARY_PATH
+On Linux, building will create a drop-in alternative for libGL.so into
-or
+ build/foo/gallium/targets/libgl-xlib/libGL.so
- export LD_LIBRARY_PATH=$PWD/build/linux-x86-debug/lib:$LD_LIBRARY_PATH
+To use it set the LD_LIBRARY_PATH environment variable accordingly.
For performance evaluation pass debug=no to scons, and use the corresponding
lib directory without the "-debug" suffix.
+On Windows, building will create a drop-in alternative for opengl32.dll. To use
+it put it in the same directory as the application. It can also be used by
+replacing the native ICD driver, but it's quite an advanced usage, so if you
+need to ask, don't even try it.
+
+
+Profiling
+=========
+
+To profile llvmpipe you should pass the options
+
+ scons build=profile <same-as-before>
+
+This will ensure that frame pointers are used both in C and JIT functions, and
+that no tail call optimizations are done by gcc.
+
+
+To better profile JIT code you'll need to build LLVM with oprofile integration.
+
+ source_dir=$PWD/llvm-2.6
+ build_dir=$source_dir/build/profile
+ install_dir=$source_dir-profile
+
+ mkdir -p "$build_dir"
+ cd "$build_dir" && \
+ $source_dir/configure \
+ --prefix=$install_dir \
+ --enable-optimized \
+ --disable-profiling \
+ --enable-targets=host-only \
+ --with-oprofile
+
+ make -C "$build_dir"
+ make -C "$build_dir" install
+
+ find "$install_dir/lib" -iname '*.a' -print0 | xargs -0 strip --strip-debug
+
+The you should define
+
+ export LLVM=/path/to/llvm-2.6-profile
+
+and rebuild.
+
Unit testing
============
then skim through the lp_bld_* functions called in there, and the comments
at the top of the lp_bld_*.c functions.
-- All lp_bld_*.[ch] are isolated from the rest of the driver, and could/may be
- put in a stand-alone Gallium state -> LLVM IR translation module.
+- The driver-independent parts of the LLVM / Gallium code are found in
+ src/gallium/auxiliary/gallivm/. The filenames and function prefixes
+ need to be renamed from "lp_bld_" to something else though.
- We use LLVM-C bindings for now. They are not documented, but follow the C++
interfaces very closely, and appear to be complete enough for code
generation. See
http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html
- for a stand-alone example.
+ for a stand-alone example. See the llvm-c/Core.h file for reference.