docs: Add list of bugs fixed in 7.9
[mesa.git] / docs / cell.html
index 34d9a92723154d0346430725928814839dca1fd7..30626b60b42be283e4985537eadfa9de484aa5a1 100644 (file)
 The Mesa
 <a href="http://en.wikipedia.org/wiki/Cell_%28microprocessor%29" target="_parent">Cell</a>
 driver is part of the 
-<a href="http://www.tungstengraphics.com/wiki/index.php/Gallium3D" target="_parent">Gallium3D</a>
+<a href="http://wiki.freedesktop.org/wiki/Software/gallium" target="_parent">Gallium3D</a>
 architecture.
-</p>
-
-<p>
-<a href="http://www.tungstengraphics.com/" target="_parent">Tungsten Graphics</a>
-is leading the project.
-Two phases are planned.
-First, to implement the framework for parallel rasterization using the Cell
-SPEs, including texture mapping.
-Second, to implement a full-featured OpenGL driver with support for GLSL, etc.
-The second phase is now underway.
+Tungsten Graphics did the original implementation of the Cell driver.
 </p>
 
 
 <H2>Source Code</H2>
 
 <p>
-The latest Cell driver source code is on the <code>gallium-0.2</code> branch
-of the Mesa git repository.
-After you've cloned the repository, check out the branch with:
+The latest Cell driver source code is on the master branch of the Mesa
+git repository.
 </p>
-<pre>
-   git-checkout -b gallium-0.2 origin/gallium-0.2
-</pre>
 <p>
 To build the driver you'll need the IBM Cell SDK (version 2.1 or 3.0).
 To use the driver you'll need a Cell system, such as a PS3 running Linux,
@@ -50,19 +37,21 @@ special changes.
 
 <p>
 To compile the code, run <code>make linux-cell</code>.
-To build in debug mode, run <code>make linux-cell-debug</code>.
+Or to build in debug mode, run <code>make linux-cell-debug</code>.
 </p>
 
 <p>
-To use the library, make sure <code>LD_LIBRARY_PATH</code> points the Mesa/lib/
-directory that contains <code>libGL.so</code>.
-</p>
+To use the library, make sure your current directory is the top of the
+Mesa tree, then set <code>LD_LIBRARY_PATH</code> like this:
+<pre>
+  export LD_LIBRARY_PATH=$PWD/lib/gallium:$PWD/lib/
+</pre>
 
 <p>
-Verify that the Cell driver is being used by running <code>glxinfo</code>
-and looking for:
+Verify that the Cell driver is being used by running
+<code>progs/xdemos/glxinfo</code> and looking for:
 <pre>
-  OpenGL renderer string: Gallium 0.2, Cell on Xlib
+  OpenGL renderer string: Gallium 0.3, Cell on Xlib
 </pre>
 
 
@@ -83,23 +72,23 @@ Similarly, textures are tiled and brought into local store as needed.
 <H2>Status</H2>
 
 <p>
-As of September 2008, the driver supports smooth/flat shaded triangle rendering
-with Z testing and simple texture mapping.
-Simple demos like gears run successfully.
-To test texture mapping, try progs/demos/texcyl (press right mouse button for
-rendering options).
+As of October 2008, the driver runs quite a few OpenGL demos.
+Features that work include:
 </p>
+<ul>
+<li>Point/line/triangle rendering, glDrawPixels
+<li>2D, NPOT and cube texture maps with nearest/linear/mipmap filtering
+<li>Dynamic SPU code generation for fragment shaders, but not complete
+<li>Dynamic SPU code generation for fragment ops (blend, Z-test, etc), but not complete
+<li>Dynamic PPU/PPC code generation for vertex shaders, but not complete
+</ul>
 <p>
-Runtime/dynamic code generation is being done for per-fragment
-operations (Z test, blend, etc) and for fragment programs (though only a
-few opcodes are implemented now).
+Performance has recently improved with the addition of PPC code generation
+for vertex shaders, but the code quality isn't too great yet.
 </p>
 <p>
-In general, however, the driver is rather slow because all vertex
-transformation is being done by an interpreter running on the PPU.
-Programs with many vertices or complex vertex shaders will run especially
-slow.
-This will be addressed in the future.
+Another bottleneck is SwapBuffers.  It may be the limiting factor for
+many simple GL tests.
 </p>
 
 
@@ -114,8 +103,20 @@ more of the following debug options:
 <li><b>checker</b> - use a different background clear color for each SPU.
    This lets you see which SPU is rendering which screen tiles.
 <li><b>sync</b> - wait/synchronize after each DMA transfer
+<li><b>asm</b> - print generated SPU assembly code to stdout
+<li><b>fragops</b> - emit fragment ops debug messages
+<li><b>fragopfallback</b> - don't use codegen for fragment ops
+<li><b>cmd</b> - print SPU commands as their received
+<li><b>cache</b> - print texture cache statistics when program exits
 </ul>
+<p>
+Note that some of these options may only work for linux-cell-debug builds.
+</p>
 
+<p>
+If the GALLIUM_NOPPC env var is set, PPC code generation will not be used
+and vertex shaders will be run with the TGSI interpreter.
+</p>
 <p>
 If the GALLIUM_NOCELL env var is set, the softpipe driver will be used
 intead of the Cell driver.