X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=src%2Fgallium%2Fdrivers%2Fllvmpipe%2FREADME;h=e9374cc6efac41ff2ba0ff505d3b91682507bacd;hb=48e191f90cbb7735cadf30c444e1fb599311c55a;hp=89d08834a3c408a4c78276024a6b1b5f6f1608ef;hpb=898de4a9d5e47ed32c600e5907476fd9338aa7e9;p=mesa.git diff --git a/src/gallium/drivers/llvmpipe/README b/src/gallium/drivers/llvmpipe/README index 89d08834a3c..e9374cc6efa 100644 --- a/src/gallium/drivers/llvmpipe/README +++ b/src/gallium/drivers/llvmpipe/README @@ -1,97 +1,57 @@ 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 + aptitude install llvm-dev - - translate the remaining bits of texture sampling state + 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. - - translate TGSI control flow instructions, and all other remaining opcodes - - - integrate with the draw module for VS code generation + For MSVC there are two set of binaries: llvm-x.x-msvc32mt.7z and + llvm-x.x-msvc32mtd.7z . - - code generate the triangle setup and rasterization + 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. + The version of LLVM from SVN ("2.7svn") from mid-March 2010 is pretty + stable and has some features not in version 2.6. -Requirements -============ + - scons (optional) - - Linux + - udis86, http://udis86.sourceforge.net/ (optional). My personal repository + supports more opcodes which haven't been merged upstream yet: - - udis86, http://udis86.sourceforge.net/ . Use my repository, which decodes - opcodes not yet supported by upstream. - - git clone git://people.freedesktop.org/~jrfonseca/udis86 + git clone git://anongit.freedesktop.org/~jrfonseca/udis86 cd udis86 + ./autogen.sh ./configure --with-pic make sudo make install - - LLVM 2.5. On Debian based distributions do: - - aptitude install llvm-dev - - There is a typo in one of the llvm-dev 2.5 headers, that causes compilation - errors in the debug build: - - --- /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 - 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(*I); - #endif - return reinterpret_cast(Vals); - - - 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. - - - scons - 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 @@ -99,22 +59,65 @@ 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 + +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 ============ @@ -139,11 +142,12 @@ Development Notes 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.