On Mon, 2009-08-31 at 01:49 -0700, José Fonseca wrote: > On Mon, 2009-08-31 at 01:14 -0700, Michel Dänzer wrote: > > Hi José, > > > > > > On Sat, 2009-08-29 at 12:04 -0700, Jose Fonseca wrote: > > > Module: Mesa > > > Branch: master > > > Commit: e173a9bbd64dc38dba6b881ed7a9faea02861042 > > > URL: > > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=e173a9bbd64dc38dba6b881ed7a9faea02861042 > > > > > > Author: José Fonseca <[email protected]> > > > Date: Sat Aug 29 20:02:25 2009 +0100 > > > > > > llvmpipe: Define an winsys for LLVM. Drop pipe_winsys > > > > > > lp_winsys will eventually be unified with softpipe's eventually, but we > > > are free to move quicker since we don't have the myriad of users yet. > > > > > > Will provide a pipe_winsys adaptor from Keith's softpipe-private-winsys > > > soon. > > > > > > --- > > > > Looks like you forgot to add the lp_buffer.c file. > > Commited. Thanks Michel. > > > BTW, unfortunately LLVM 2.5 can't seem to handle llvmpipe on Linux/PPC. > > I'm attaching the full stderr output from glxgears, but the upshot is: > > > > SplitVectorOperand Op #0: 0x10540ae8: f32 = select_cc 0x1052baf0, > > 0x1052c590, 0x1052c508, 0x10540a60, 0x1050c998 > > glxgears: > > /build/buildd/llvm-2.5/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:861: > > bool llvm::DAGTypeLegalizer::SplitVectorOperand(llvm::SDNode*, unsigned > > int): Assertion `0 && "Do not know how to split this operator's operand!"' > > failed. > > > > But this is most likely an LLVM issue, so don't worry about it unless > > you have an idea for a workaround offhand. > > Yes, this is a known LLVM limitation for all targets -- it can represent > selection (like the C '?' ternary operator) of vectors but no machine > target can actually support it yet. The temporary solution is to emit > SIMD intrinsics for comparison directly. If you can somehow implement > lp_bld_logic.c's lp_build_cmp() function in terms of altivec intrinsics > then it should work. > > Another last-resource solution is to manually break the vector > comparison in element-wise comparisons,
Done. Give it another try. > but performance will suck > drastically, since we use these a lot for color saturation/clamping. Actually performance it's not so bad -- gloss fps drops 10% if I disable intrinsics. Not the end of the world. I guess that's because addition/multiplications, which are far more often, are handled fine with vanilla LLVM IR. > There are not many, but there are at least a couple other corner cases > like this -- where vanilla LLVM IR isn't good enough. But I didn't spot > any other in your log. I think one of the cases that will cause problem is blending with non constant factors, because 8bit unsigned multiplication isn't usually supported by SIMD instruction sets, and needs special treatment, like the one done in lp_build_mul / lp_build_mul_u8n. Jose ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
