diff options
| -rw-r--r-- | docs/llvmpipe.html | 55 |
1 files changed, 32 insertions, 23 deletions
diff --git a/docs/llvmpipe.html b/docs/llvmpipe.html index 90001e177fe..c7d0dd4652a 100644 --- a/docs/llvmpipe.html +++ b/docs/llvmpipe.html @@ -47,7 +47,7 @@ It's the fastest software rasterizer for Mesa. built with LLVM version 4.0 or later. </p> <p> - See /proc/cpuinfo to know what your CPU supports. + See <code>/proc/cpuinfo</code> to know what your CPU supports. </p> </li> <li> @@ -73,8 +73,9 @@ It's the fastest software rasterizer for Mesa. <p> For Windows you will need to build LLVM from source with MSVC or MINGW - (either natively or through cross compilers) and CMake, and set the LLVM - environment variable to the directory you installed it to. + (either natively or through cross compilers) and CMake, and set the + <code>LLVM</code> environment variable to the directory you installed + it to. LLVM will be statically linked, so when building on MSVC it needs to be built with a matching CRT as Mesa, and you'll need to pass @@ -103,8 +104,8 @@ It's the fastest software rasterizer for Mesa. </table> <p> - You can build only the x86 target by passing -DLLVM_TARGETS_TO_BUILD=X86 - to cmake. + You can build only the x86 target by passing + <code>-DLLVM_TARGETS_TO_BUILD=X86</code> to cmake. </p> </li> @@ -143,7 +144,8 @@ For Windows the procedure is similar except the target: <h3>Linux</h3> -<p>On Linux, building will create a drop-in alternative for libGL.so into</p> +<p>On Linux, building will create a drop-in alternative for +<code>libGL.so</code> into</p> <pre> build/foo/gallium/targets/libgl-xlib/libGL.so @@ -153,10 +155,12 @@ or lib/gallium/libGL.so </pre> -<p>To use it set the LD_LIBRARY_PATH environment variable accordingly.</p> +<p>To use it set the <code>LD_LIBRARY_PATH</code> environment variable +accordingly.</p> -<p>For performance evaluation pass build=release to scons, and use the corresponding -lib directory without the "-debug" suffix.</p> +<p>For performance evaluation pass <code>build=release</code> to scons, +and use the corresponding lib directory without the <code>-debug</code> +suffix.</p> <h3>Windows</h3> @@ -177,7 +181,9 @@ any OpenGL drivers): </p> <ul> - <li><p>copy build/windows-x86-debug/gallium/targets/libgl-gdi/opengl32.dll to C:\Windows\SysWOW64\mesadrv.dll</p></li> + <li><p>copy <code>build/windows-x86-debug/gallium/targets/libgl-gdi/opengl32.dll</code> + to <code>C:\Windows\SysWOW64\mesadrv.dll</code> + </p></li> <li><p>load this registry settings:</p> <pre>REGEDIT4 @@ -220,10 +226,11 @@ On Linux, it is possible to have symbol resolution of JIT code with <a href="htt </pre> <p> -When run inside Linux perf, llvmpipe will create a /tmp/perf-XXXXX.map file with -symbol address table. It also dumps assembly code to /tmp/perf-XXXXX.map.asm, -which can be used by the bin/perf-annotate-jit.py script to produce disassembly of -the generated code annotated with the samples. +When run inside Linux perf, llvmpipe will create a +<code>/tmp/perf-XXXXX.map</code> file with symbol address table. It also +dumps assembly code to <code>/tmp/perf-XXXXX.map.asm</code>, which can be +used by the <code>bin/perf-annotate-jit.py</code> script to produce +disassembly of the generated code annotated with the samples. </p> <p>You can obtain a call graph via @@ -234,13 +241,13 @@ the generated code annotated with the samples. <p> Building will also create several unit tests in -build/linux-???-debug/gallium/drivers/llvmpipe: +<code>build/linux-???-debug/gallium/drivers/llvmpipe</code>: </p> <ul> -<li> lp_test_blend: blending -<li> lp_test_conv: SIMD vector conversion -<li> lp_test_format: pixel unpacking/packing +<li> <code>lp_test_blend</code>: blending +<li> <code>lp_test_conv</code>: SIMD vector conversion +<li> <code>lp_test_format</code>: pixel unpacking/packing </ul> <p> @@ -257,20 +264,22 @@ for later analysis, e.g.: <ul> <li> When looking at this code for the first time, start in lp_state_fs.c, and - then skim through the lp_bld_* functions called there, and the comments - at the top of the lp_bld_*.c functions. + then skim through the <code>lp_bld_*</code> functions called there, and + the comments at the top of the <code>lp_bld_*.c</code> functions. </li> <li> 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. + <code>src/gallium/auxiliary/gallivm/</code>. The filenames and function + prefixes need to be renamed from <code>lp_bld_</code> to something else + though. </li> <li> 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 <a href="https://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html"> - this stand-alone example</a>. See the llvm-c/Core.h file for reference. + this stand-alone example</a>. See the <code>llvm-c/Core.h</code> file for + reference. </li> </ul> |