FYI, I've just pushed a branch named llvmpipe-wider-regs, which allows llvmpipe to leverage SIMD registers wider than 128bits.
Unfortunately, performance-wise this doesn't change much, as llvmpipe performance is dominated by integer SIMD instructions, whereas currently the AVX instruction set currently only supports floating SIMD instructions. Actually, often things will get slightly slower, as there are considerable overheads in piecing together the 256 floating point code paths and 128-bit integer code paths. The benefit for this change is foremost architectural: llvmpipe now makes less assumptions regarding the number of pixels/quads/etc that fit into a hardware register, a flexibility which will be necessary to get things like per-pixel LOD working properly. This barely touch files outside gallivm/draw/llvmpipe modules. I haven't tested i915g, r300g, so let me know if there are regressions / concerns. I'd like to merge this into master soon. LLVM 3.1 and an AVX-enabled processor is required to actually exercise the 256bit register code paths. One of the downsides is that MC-JIT is required to use emit VEX instructions, but MC-JIT is not very polished yet (e.g, we need to create one MC-JIT instance for every LLVM module). I think that with LLVM 3.2 this should be less of an issue. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
