Results 1 to 8 of 8

Thread: Auto-Vectorizing LLVMpipe For Performance Gains

  1. #1
    Join Date
    Jan 2007
    Posts
    15,088

    Default Auto-Vectorizing LLVMpipe For Performance Gains

    Phoronix: Auto-Vectorizing LLVMpipe For Performance Gains

    Here's a hint that may allow for some notable performance gains out of the Gallium3D LLVMpipe driver for multi-core systems...

    http://www.phoronix.com/vr.php?view=MTExMjc

  2. #2
    Join Date
    Jan 2012
    Location
    Moscow
    Posts
    61

    Default Correction

    LLVMpipe is now used as the fallback for Ubuntu and Fedora when no hardware GPU driver is available.
    Ubuntu 12.04 still uses the bloody slow softpipe. 12.10 is expected to use llvmpipe.

  3. #3
    Join Date
    Dec 2011
    Posts
    2,098

    Default Interesting

    I wonder how a highly optimized LLVMpipe would perform?

  4. #4
    Join Date
    May 2012
    Posts
    29

    Default

    Quote Originally Posted by uid313 View Post
    I wonder how a highly optimized LLVMpipe would perform?
    Not quite sure what you mean there - I think it is pretty well optimized - it has some code just to make it faster already (like aos texture sampling for performance, brilinear filtering). There's of course always more you could do, and the current public code has has some little performance shortcomings especially in the draw code but this doesn't really matter for llvmpipe.

    And while I agree that the pass manager probably isn't quite optimal, I can't see how autovectorization would do much for llvmpipe. The reason is that pretty much everything is already explicitly vectorized manually anyway.

  5. #5
    Join Date
    Dec 2011
    Posts
    2,098

    Default

    Quote Originally Posted by mczak View Post
    Not quite sure what you mean there - I think it is pretty well optimized - it has some code just to make it faster already (like aos texture sampling for performance, brilinear filtering). There's of course always more you could do, and the current public code has has some little performance shortcomings especially in the draw code but this doesn't really matter for llvmpipe.

    And while I agree that the pass manager probably isn't quite optimal, I can't see how autovectorization would do much for llvmpipe. The reason is that pretty much everything is already explicitly vectorized manually anyway.
    I interpreted the post as if there were almost no optimizations being done.

  6. #6
    Join Date
    May 2012
    Posts
    29

    Default

    Quote Originally Posted by uid313 View Post
    I interpreted the post as if there were almost no optimizations being done.
    Ah wrt optimization passes. I'm nearly sure we're missing some, I actually tried some because for instance the code generated for loading constants is pretty terrible but without much success. Most of the passes however don't seem to do much for this code anyway. The problem is there is a gazillion passes available and it's damn near impossible to tell which ones should probably be enabled (and in which order) and which ones aren't all that important. I've also seen terrible code being generated wrt spills/reloads (for example spill/reload without actually using the register in-between) but I'm not sure if optimization passes could solve that or if the spill code is just terrible...

  7. #7
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    877

    Default

    I don't know too horribly much about the LLVM optimization passes, but after watching the conference video and going through the slides, I attempted to add the proposed modifications from the post.

    I had to modify configure.ac to add the LLVMVectorize library to the LD_FLAGS (via appropriate llvm-config tomfoolery), and was able to get it to build correctly when the <llvm/Transforms/Vectorize.h> header was included... however, many piglit quick-driver tests crashed outright either with Floating Point Exceptions, Segmentation Faults, or other errors. I'm sure there's plenty that I missed, and I haven't had much time to play with it, but unfortunately, it's not just a drop-in, fool-proof optimization.

  8. #8
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by Veerappan View Post
    I don't know too horribly much about the LLVM optimization passes, but after watching the conference video and going through the slides, I attempted to add the proposed modifications from the post.

    I had to modify configure.ac to add the LLVMVectorize library to the LD_FLAGS (via appropriate llvm-config tomfoolery), and was able to get it to build correctly when the <llvm/Transforms/Vectorize.h> header was included... however, many piglit quick-driver tests crashed outright either with Floating Point Exceptions, Segmentation Faults, or other errors. I'm sure there's plenty that I missed, and I haven't had much time to play with it, but unfortunately, it's not just a drop-in, fool-proof optimization.

    yeah I tried the same thing, and gears didn't start, it dies inside that optimisation pass somewhere. I've no idea how to figure it out either :-)

    Dave.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •