nv50-nvc0: set cur_ctx during init if none currently bound
[mesa.git] / src / gallium / drivers / llvmpipe / README
index 0c3f00fd58f89b69b57821c803a37d00f3b7c3aa..e9374cc6efac41ff2ba0ff505d3b91682507bacd 100644 (file)
@@ -1,56 +1,9 @@
 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
  - A x86 or amd64 processor.  64bit mode is preferred.
  
    Support for sse2 is strongly encouraged.  Support for ssse3, and sse4.1 will
@@ -59,32 +12,33 @@ Requirements
    
    See /proc/cpuinfo to know what your CPU supports.
  
- - LLVM 2.5 or greater. LLVM 2.6 is preferred.
+ - LLVM 2.6 (or later)
  
-   On Debian based distributions do:
+   For Linux, on a recent Debian based distribution do:
  
      aptitude install llvm-dev
 
-   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);
+   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 .
+
+   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
@@ -95,9 +49,9 @@ Requirements
 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
 
@@ -105,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 <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
 ============
@@ -145,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.