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
============
- Linux
- - LLVM. On Debian based distributions do:
+ - udis86, http://udis86.sourceforge.net/ . Use my repository, which decodes
+ opcodes not yet supported by upstream.
+
+ git clone git://people.freedesktop.org/~jrfonseca/udis86
+ cd udis86
+ ./configure --with-pic
+ make
+ sudo make install
+
+ - LLVM 2.5. On Debian based distributions do:
aptitude install llvm-dev
- There is a type in one of the llvm-dev 2.5 headers, that causes compilation
+ 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
instructions. This is necessary because we emit several SSE intrinsics for
convenience. See /proc/cpuinfo to know what your CPU supports.
- - scons (although it should be straightforward to fix the Makefiles as well)
+ - scons
Building
scons debug=yes statetrackers=mesa drivers=llvmpipe winsys=xlib dri=false -k
+Alternatively, you can build it with GNU make, if you prefer, by invoking it as
+
+ make linux-llvm
+
+but the rest of these instructions assume that scons is used.
+
Using
=====
Building will create a drop-in alternative for libGL.so. To use it set the
environment variables:
- export LD_LIRBARY_PATH=$PWD/build/linux-x86-debug/lib:$LD_LIRBARY_PATH
- export LD_LIRBARY_PATH=$PWD/build/linux-x86_64-debug/lib:$LD_LIRBARY_PATH
+ export LD_LIBRARY_PATH=$PWD/build/linux-x86_64-debug/lib:$LD_LIBRARY_PATH
+
+or
+
+ export LD_LIBRARY_PATH=$PWD/build/linux-x86-debug/lib:$LD_LIBRARY_PATH
+
+For performance evaluation pass debug=no to scons, and use the corresponding
+lib directory without the "-debug" suffix.
Unit testing
- lp_test_conv: SIMD vector conversion
- lp_test_format: pixel unpacking/packing
+Some of this tests can output results and benchmarks to a tab-separated-file
+for posterior analysis, e.g.:
+
+ build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
+
+
+Development Notes
+=================
+
+- When looking to this code by the first time start in lp_state_fs.c, and
+ 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.
+- 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.
projects / mesa.git / blobdiff