X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=src%2Fgallium%2Fdrivers%2Fllvmpipe%2FREADME;h=e9374cc6efac41ff2ba0ff505d3b91682507bacd;hb=48e191f90cbb7735cadf30c444e1fb599311c55a;hp=bf4c9a5727c3ba4c9c6bf775b01cced669a5b9d7;hpb=685340a53e1dcb2a888e634ee71ba24356befe69;p=mesa.git diff --git a/src/gallium/drivers/llvmpipe/README b/src/gallium/drivers/llvmpipe/README index bf4c9a5727c..e9374cc6efa 100644 --- a/src/gallium/drivers/llvmpipe/README +++ b/src/gallium/drivers/llvmpipe/README @@ -1,51 +1,6 @@ LLVMPIPE -- a fork of softpipe that employs LLVM for code generation. -Status -====== - -Done so far is: - - - the whole fragment pipeline is code generated in a single function - - - input interpolation - - - depth testing - - - texture sampling (not all state/formats are supported) - - - 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 - - - alpha testing - - - blend (including logic ops) - - both in SoA and AoS layouts, but only the former used for now - - - 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 - - - code generate the triangle setup and rasterization - - Requirements ============ @@ -57,7 +12,7 @@ Requirements See /proc/cpuinfo to know what your CPU supports. - - LLVM 2.6. + - LLVM 2.6 (or later) For Linux, on a recent Debian based distribution do: @@ -67,11 +22,23 @@ Requirements 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 . + + 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. + - 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 @@ -84,7 +51,7 @@ Building To build everything on Linux invoke scons as: - scons debug=yes statetrackers=mesa drivers=llvmpipe winsys=xlib dri=false + scons build=debug libgl-xlib Alternatively, you can build it with GNU make, if you prefer, by invoking it as @@ -94,19 +61,16 @@ but the rest of these instructions assume that scons is used. For windows is everything the except except the winsys: - scons debug=yes statetrackers=mesa drivers=llvmpipe winsys=gdi dri=false + scons build=debug libgl-gdi Using ===== -On Linux, building will create a drop-in alternative for libGL.so. To use it -set the environment variables: +On Linux, building will create a drop-in alternative for libGL.so into - export LD_LIBRARY_PATH=$PWD/build/linux-x86_64-debug/lib:$LD_LIBRARY_PATH + build/foo/gallium/targets/libgl-xlib/libGL.so -or - - 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. @@ -117,6 +81,44 @@ 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 ============ @@ -140,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.