aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/cell/spu/spu_main.h
Commit message (Collapse)AuthorAgeFilesLines
* cell: remove commas from structs wrapped in PIPE_ALIGN_TYPE macroBrian Paul2010-01-271-7/+18
| | | | This avoids the need to make PIPE_ALIGN_TYPE a variadic macro.
* gallium: Simplify PIPE_ALIGN_VAR.José Fonseca2010-01-121-5/+5
| | | | | | gcc allows pre-fix variable attributes. Suggested by Ian Romanick.
* gallium: Generalize the alignment macros to other compilers and any alignment.José Fonseca2010-01-121-9/+13
|
* CELL: use variant-length fragment ops programsRobert Ellison2008-11-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a set of changes that optimizes the memory use of fragment operation programs (by using and transmitting only as much memory as is needed for the fragment ops programs, instead of maximal sizes), as well as eliminate the dependency on hard-coded maximal program sizes. State that is not dependent on fragment facing (i.e. that isn't using two-sided stenciling) will only save and transmit a single fragment operation program, instead of two identical programs. - Added the ability to emit a LNOP (No Operation (Load)) instruction. This is used to pad the generated fragment operations programs to a multiple of 8 bytes, which is necessary for proper operation of the dual instruction pipeline, and also required for proper SPU-side decoding. - Added the ability to allocate and manage a variant-length struct cell_command_fragment_ops. This structure now puts the generated function field at the end, where it can be as large as necessary. - On the PPU side, we now combine the generated front-facing and back-facing code into a single variant-length buffer (and only use one if the two sets of code are identical) for transmission to the SPU. - On the SPU side, we pull the correct sizes out of the buffer, allocate a new code buffer if the one we have isn't large enough, and save the code to that buffer. The buffer is deallocated when the SPU exits. - Commented out the emit_fetch() static function, which was not being used.
* CELL: two-sided stencil fixesRobert Ellison2008-11-111-5/+5
| | | | | | | | | | | | | | | | | | | With these changes, the tests/stencil_twoside test now works. - Eliminate blending from the stencil_twoside test, as it produces an unneeded dependency on having blending working - The spe_splat() function will now work if the register being splatted and the destination register are the same - Separate fragment code generated for front-facing and back-facing fragments. Often these are the same; if two-sided stenciling is on, they can be different. This is easier and faster than generating code that does both tests and merges the results. - Fixed a cut/paste bug where if the back Z-pass stencil operation were different from all the other operations, the back Z-fail results were incorrect.
* CELL: stencil bug fixesRobert Ellison2008-10-301-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Two definitive bugs in stenciling were fixed. The first, reversed registers in the generated Select Bytes (selb) instruction, caused the stenciling INCR and DECR operations to fail dramatically, putting new values in where old values were supposed to be and vice versa. The second caused stencil tiles to not be read and written from main memory by the SPUs. A per-spu flag, spu.read_depth, was used to indicate whether the SPU should be reading depth tiles, and was set only when depth was enabled. A second flag, spu.read_stencil, was set when stenciling was enabled, but never referenced. As stenciling and depth are in the same tiles on the Cell, and there is no corresponding TAG_WRITE_TILE_STENCIL to complement TAG_WRITE_TILE_COLOR and TAG_WRITE_TILE_Z, I fixed this by eliminating the unused "spu.read_stencil", renaming "spu.read_depth" to "spu.read_depth_stencil", and setting it if either stenciling or depth is enabled. I also added an optimization to the fragment ops generation code, that avoids calculating stencil values and/or stencil writemask when the stencil operations are all KEEP.
* cell: implement fencing for texture buffersBrian Paul2008-10-221-1/+1
| | | | | | | If we delete a texture, we need to keep the underlying tiled data buffer around until any rendering that references it has completed. Keep a list of buffers referenced by a rendering batch. Unref/free them when the associated batch's fence is executed/signalled.
* cell: implement KIL instructionBrian Paul2008-10-161-3/+3
|
* cell: clean up various texture-related thingsBrian Paul2008-10-161-9/+7
| | | | | Distinguish among texture targets in codegen. progs/demos/cubemap.c runs correctly now too.
* cell: send rasterizer state to SPUs in proper way, remove front_winding hackBrian Paul2008-10-151-0/+1
|
* cell: move some CELL_MAX constantsBrian Paul2008-10-151-9/+2
|
* cell: simplify spu debug codeBrian Paul2008-10-151-2/+13
|
* cell: propogate blend color to SPUs for the fallback fragment ops codeBrian Paul2008-10-151-0/+1
|
* cell: initial bits for 3D texture supportBrian Paul2008-10-141-4/+4
|
* cell: support for cubemapsBrian Paul2008-10-141-1/+3
| | | | Though, progs/demos/cubemap.c doesn't quite work right...
* cell: support NPOT textures, clamp/repeat mode, normalized/unorm texcoordsBrian Paul2008-10-141-4/+8
| | | | glDrawPixels works now.
* cell: use minify vs magnify filtersBrian Paul2008-10-141-0/+2
|
* cell: basic mipmap filtering works nowBrian Paul2008-10-141-1/+2
| | | | Though, only GL_MIPMAP_NEAREST / GL_LINEAR works right now.
* cell: initial work for mipmap texture filteringBrian Paul2008-10-131-1/+6
|
* cell: remove old texture-related fieldsBrian Paul2008-10-131-2/+0
|
* cell: remove old texture codeBrian Paul2008-10-131-4/+0
|
* cell: do texture sampling/filtering for four pixels at a time.Brian Paul2008-10-131-4/+15
|
* cell: add support for fragment shader constant buffersBrian Paul2008-10-071-3/+5
|
* CELL: changes to generate SPU code for stencilingRobert Ellison2008-10-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This set of code changes are for stencil code generation support. Both one-sided and two-sided stenciling are supported. In addition to the raw code generation changes, these changes had to be made elsewhere in the system: - Added new "register set" feature to the SPE assembly generation. A "register set" is a way to allocate multiple registers and free them all at the same time, delegating register allocation management to the spe_function unit. It's quite useful in complex register allocation schemes (like stenciling). - Added and improved SPE macro calculations. These are operations between registers and unsigned integer immediates. In many cases, the calculation can be performed with a single instruction; the macros will generate the single instruction if possible, or generate a register load and register-to-register operation if not. These macro functions are: spe_load_uint() (which has new ways to load a value in a single instruction), spe_and_uint(), spe_xor_uint(), spe_compare_equal_uint(), and spe_compare_greater_uint(). - Added facing to fragment generation. While rendering, the rasterizer needs to be able to determine front- and back-facing fragments, in order to correctly apply two-sided stencil. That requires these changes: - Added front_winding field to the cell_command_render block, so that the state tracker could communicate to the rasterizer what it considered to be the front-facing direction. - Added fragment facing as an input to the fragment function. - Calculated facing is passed during emit_quad().
* cell: align instruction buffers to 8-byte, not 32-byte boundaryBrian Paul2008-09-261-4/+4
|
* cell: make sure the fragment ops and fragment shader code buffer is at a ↵Brian Paul2008-09-191-4/+4
| | | | | | 32-byte boundary To make sure even/odd instructions hit the right pipes.
* cell: initial support for fragment shader code generation.Brian Paul2008-09-111-0/+15
| | | | | | TGSI shaders are translated into SPE instructions which are then sent to the SPEs for execution. Only a few opcodes work, no swizzling yet, no support for constants/immediates, etc.
* cell: asst. clean-upBrian Paul2008-09-111-26/+21
|
* cell: checkpoint: remove more of the old per-fragment codeBrian Paul2008-09-111-36/+1
|
* cell: checkpoint commit of new per-fragment processingBrian Paul2008-09-111-0/+23
| | | | | | | Do code generation for alpha test, z test, stencil, blend, colormask and framebuffer/tile read/write as a single code block. Ian's previous blend/z/stencil test code is still there but mostly disabled and will be removed soon.
* cell: minor change to Z float/int conversion code (avoid switch)Brian Paul2008-09-111-0/+5
|
* cell: code clean-up, commentsBrian Paul2008-09-051-4/+4
|
* cell: minor texture improvementsBrian2008-04-031-1/+2
| | | | Precompute tiles_per_row. Use ushort multiplies in a few places. New comments.
* cell: more multi-texture fixes (mostly working now)Brian2008-04-011-1/+3
|
* cell: checkpoint: more multi-texture workBrian2008-04-011-1/+1
|
* cell: more work for multi-texture supportBrian2008-03-311-6/+12
|
* cell: initial work to support multi-textureBrian2008-03-311-4/+4
|
* cell: Implement code-gen for logic opIan Romanick2008-03-261-1/+8
| | | | | | | This also implements code-gen for the float-to-packed color conversion. It's currently hardcoded for A8R8G8B8, but that can easily be fixed as soon as other color depths are supported by the Cell driver.
* cell: Change code-gen for CONST_COLOR blend factorIan Romanick2008-03-211-0/+2
| | | | | | | | | | | | Previously the constant color blend factor was compiled into the generated code. This meant that the code had to be regenerated each time the constant color was changed. This doesn't fit with the model used in Gallium. As-is, the code could be better. The constant color is loaded for every quad processed, even if it is not used. Also, if a lot of (1-x) blend factors are used, 1.0 will be loaded and reloaded into registers many times.
* cell: Use code-gen for alpha blendIan Romanick2008-03-201-1/+16
| | | | So far this is only tested when GL_BLEND is disabled.
* cell: Initial code-gen for alpha / stencil / depth testingIan Romanick2008-03-171-2/+14
| | | | | | | | Alpha test is currently broken because all per-fragment testing occurs before alpha is calculated. Stencil test is currently broken because the Z-clear code asserts if there is a stencil buffer.
* cell: Use unified data cache for textures tooIan Romanick2008-02-271-1/+2
|
* Cell: Use multiple DMA tags for the dcache.Ian Romanick2008-02-251-1/+4
|
* Code reorganization: update build.José Fonseca2008-02-151-2/+2
| | | | | | | | | Update the Makefiles and includes for the new paths. Note that there hasn't been no separation of the Makefiles yet, and make is jumping all over the place. That will be taken care shortly. But for now, make should work. It was tested with linux and linux-dri. Linux-cell and linux-llvm might require some minor tweaks.
* Code reorganization: move files into their places.José Fonseca2008-02-151-0/+177
This is in a separate commit to ensure renames are properly preserved.