summaryrefslogtreecommitdiff
path: root/lib/mesa/docs/llvmpipe.html
diff options
context:
space:
mode:
authorJonathan Gray <jsg@cvs.openbsd.org>2018-10-23 06:36:00 +0000
committerJonathan Gray <jsg@cvs.openbsd.org>2018-10-23 06:36:00 +0000
commitb65fcab046d3a1b6b6ac315720df220925c5322e (patch)
treeff73dcc383ac0799c655ff6194cda9dacb75dde9 /lib/mesa/docs/llvmpipe.html
parent18d6381c51e253e4c41c62619f80d9ce745b95c8 (diff)
Merge Mesa 17.3.9
Mesa 18.x needs an ld with build-id for at least the intel code Mesa 18.2 assumes linux only memfd syscalls in intel code Tested by matthieu@, kettenis@ and myself on a variety of hardware and architectures. ok kettenis@
Diffstat (limited to 'lib/mesa/docs/llvmpipe.html')
-rw-r--r--lib/mesa/docs/llvmpipe.html56
1 files changed, 34 insertions, 22 deletions
diff --git a/lib/mesa/docs/llvmpipe.html b/lib/mesa/docs/llvmpipe.html
index f603bd646..f500cf37c 100644
--- a/lib/mesa/docs/llvmpipe.html
+++ b/lib/mesa/docs/llvmpipe.html
@@ -20,7 +20,7 @@
The Gallium llvmpipe driver is a software rasterizer that uses LLVM to
do runtime code generation.
Shaders, point/line/triangle rasterization and vertex processing are
-implemented with LLVM IR which is translated to x86 or x86-64 machine
+implemented with LLVM IR which is translated to x86, x86-64, or ppc64le machine
code.
Also, the driver is multithreaded to take advantage of multiple CPU cores
(up to 8 at this time).
@@ -32,18 +32,24 @@ It's the fastest software rasterizer for Mesa.
<ul>
<li>
- <p>An x86 or amd64 processor; 64-bit mode recommended.</p>
<p>
- Support for SSE2 is strongly encouraged. Support for SSSE3 and SSE4.1 will
+ For x86 or amd64 processors, 64-bit mode is recommended.
+ Support for SSE2 is strongly encouraged. Support for SSE3 and SSE4.1 will
yield the most efficient code. The fewer features the CPU has the more
- likely is that you run into underperforming, buggy, or incomplete code.
+ likely it is that you will run into underperforming, buggy, or incomplete code.
+ </p>
+ <p>
+ For ppc64le processors, use of the Altivec feature (the Vector
+ Facility) is recommended if supported; use of the VSX feature (the
+ Vector-Scalar Facility) is recommended if supported AND Mesa is
+ built with LLVM version 4.0 or later.
</p>
<p>
See /proc/cpuinfo to know what your CPU supports.
</p>
</li>
<li>
- <p>LLVM: version 3.4 recommended; 3.3 or later required.</p>
+ <p>Unless otherwise stated, LLVM version 3.4 is recommended; 3.3 or later is required.</p>
<p>
For Linux, on a recent Debian based distribution do:
</p>
@@ -51,6 +57,12 @@ It's the fastest software rasterizer for Mesa.
aptitude install llvm-dev
</pre>
<p>
+ If you want development snapshot builds of LLVM for Debian and derived
+ distributions like Ubuntu, you can use the APT repository at <a
+ href="https://apt.llvm.org/" title="Debian Development packages for LLVM"
+ >apt.llvm.org</a>, which are maintained by Debian's LLVM maintainer.
+ </p>
+ <p>
For a RPM-based distribution do:
</p>
<pre>
@@ -165,8 +177,8 @@ any OpenGL drivers):
<li><p>load this registry settings:</p>
<pre>REGEDIT4
-; http://technet.microsoft.com/en-us/library/cc749368.aspx
-; http://www.msfn.org/board/topic/143241-portable-windows-7-build-from-winpe-30/page-5#entry942596
+; https://technet.microsoft.com/en-us/library/cc749368.aspx
+; https://www.msfn.org/board/topic/143241-portable-windows-7-build-from-winpe-30/page-5#entry942596
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\OpenGLDrivers\MSOGL]
"DLL"="mesadrv.dll"
"DriverVersion"=dword:00000001
@@ -195,7 +207,7 @@ that no tail call optimizations are done by gcc.
<h2>Linux perf integration</h2>
<p>
-On Linux, it is possible to have symbol resolution of JIT code with <a href="http://perf.wiki.kernel.org/">Linux perf</a>:
+On Linux, it is possible to have symbol resolution of JIT code with <a href="https://perf.wiki.kernel.org/">Linux perf</a>:
</p>
<pre>
@@ -206,12 +218,12 @@ On Linux, it is possible to have symbol resolution of JIT code with <a href="htt
<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 script to produce disassembly of
+which can be used by the bin/perf-annotate-jit.py script to produce disassembly of
the generated code annotated with the samples.
</p>
<p>You can obtain a call graph via
-<a href="http://code.google.com/p/jrfonseca/wiki/Gprof2Dot#linux_perf">Gprof2Dot</a>.</p>
+<a href="https://github.com/jrfonseca/gprof2dot#linux-perf">Gprof2Dot</a>.</p>
<h1>Unit testing</h1>
@@ -228,8 +240,8 @@ build/linux-???-debug/gallium/drivers/llvmpipe:
</ul>
<p>
-Some of this tests can output results and benchmarks to a tab-separated-file
-for posterior analysis, e.g.:
+Some of these tests can output results and benchmarks to a tab-separated file
+for later analysis, e.g.:
</p>
<pre>
build/linux-x86_64-debug/gallium/drivers/llvmpipe/lp_test_blend -o blend.tsv
@@ -240,8 +252,8 @@ for posterior analysis, e.g.:
<ul>
<li>
- 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
+ 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.
</li>
<li>
@@ -253,7 +265,7 @@ for posterior analysis, e.g.:
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="http://npcontemplation.blogspot.com/2008/06/secret-of-llvm-c-bindings.html">
+ <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.
</li>
</ul>
@@ -264,18 +276,18 @@ for posterior analysis, e.g.:
<li>
<p>Rasterization</p>
<ul>
- <li><a href="http://www.cs.unc.edu/~olano/papers/2dh-tri/">Triangle Scan Conversion using 2D Homogeneous Coordinates</a></li>
+ <li><a href="https://www.cs.unc.edu/~olano/papers/2dh-tri/">Triangle Scan Conversion using 2D Homogeneous Coordinates</a></li>
<li><a href="http://www.drdobbs.com/parallel/rasterization-on-larrabee/217200602">Rasterization on Larrabee</a> (<a href="http://devmaster.net/posts/2887/rasterization-on-larrabee">DevMaster copy</a>)</li>
<li><a href="http://devmaster.net/posts/6133/rasterization-using-half-space-functions">Rasterization using half-space functions</a></li>
<li><a href="http://devmaster.net/posts/6145/advanced-rasterization">Advanced Rasterization</a></li>
- <li><a href="http://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/">Optimizing Software Occlusion Culling</a></li>
+ <li><a href="https://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/">Optimizing Software Occlusion Culling</a></li>
</ul>
</li>
<li>
<p>Texture sampling</p>
<ul>
<li><a href="http://chrishecker.com/Miscellaneous_Technical_Articles#Perspective_Texture_Mapping">Perspective Texture Mapping</a></li>
- <li><a href="http://www.flipcode.com/archives/Texturing_As_In_Unreal.shtml">Texturing As In Unreal</a></li>
+ <li><a href="https://www.flipcode.com/archives/Texturing_As_In_Unreal.shtml">Texturing As In Unreal</a></li>
<li><a href="http://www.gamasutra.com/view/feature/3301/runtime_mipmap_filtering.php">Run-Time MIP-Map Filtering</a></li>
<li><a href="http://alt.3dcenter.org/artikel/2003/10-26_a_english.php">Will "brilinear" filtering persist?</a></li>
<li><a href="http://ixbtlabs.com/articles2/gffx/nv40-rx800-3.html">Trilinear filtering</a></li>
@@ -294,21 +306,21 @@ for posterior analysis, e.g.:
<li><a href="http://www.drdobbs.com/optimizing-pixomatic-for-modern-x86-proc/184405807">Optimizing Pixomatic For Modern x86 Processors</a></li>
<li><a href="http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-optimization-manual.html">Intel 64 and IA-32 Architectures Optimization Reference Manual</a></li>
<li><a href="http://www.agner.org/optimize/">Software optimization resources</a></li>
- <li><a href="http://software.intel.com/en-us/articles/intel-intrinsics-guide">Intel Intrinsics Guide</a><li>
+ <li><a href="https://software.intel.com/en-us/articles/intel-intrinsics-guide">Intel Intrinsics Guide</a><li>
</ul>
</li>
<li>
<p>LLVM</p>
<ul>
<li><a href="http://llvm.org/docs/LangRef.html">LLVM Language Reference Manual</a></li>
- <li><a href="http://npcontemplation.blogspot.co.uk/2008/06/secret-of-llvm-c-bindings.html">The secret of LLVM C bindings</a></li>
+ <li><a href="https://npcontemplation.blogspot.co.uk/2008/06/secret-of-llvm-c-bindings.html">The secret of LLVM C bindings</a></li>
</ul>
</li>
<li>
<p>General</p>
<ul>
- <li><a href="http://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/">A trip through the Graphics Pipeline</a></li>
- <li><a href="http://msdn.microsoft.com/en-us/library/gg615082.aspx#architecture">WARP Architecture and Performance</a></li>
+ <li><a href="https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/">A trip through the Graphics Pipeline</a></li>
+ <li><a href="https://msdn.microsoft.com/en-us/library/gg615082.aspx#architecture">WARP Architecture and Performance</a></li>
</ul>
</li>
</ul>