Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Gallium3D's LLVMpipe Is Much Faster With Mesa 9.2

  1. #1
    Join Date
    Jan 2007
    Posts
    13,397

    Default Gallium3D's LLVMpipe Is Much Faster With Mesa 9.2

    Phoronix: Gallium3D's LLVMpipe Is Much Faster With Mesa 9.2

    This morning I posted new Radeon Gallium3D - Mesa 9.1 vs. Mesa 9.2 benchmarks, which showed the upcoming Mesa release performing nicely for AMD APU graphics. However, what is the performance like the software-based LLVMpipe driver that is commonly being used in fallback situations where there is no GPU hardware driver available? It's generally a lot faster now for handling OpenGL...

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

  2. #2
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    124

    Default

    Very nice work! Those are some impressive speedups.

  3. #3
    Join Date
    Apr 2011
    Posts
    31

    Default

    Now if only Michael would do a decent job of looking into why this speed improved rather than just posting some meaningless benchmarks that'd be great.

    Then again, that would be expecting him to do work which much be a scary thought.

  4. #4

    Default

    Quote Originally Posted by Jonimus View Post
    Now if only Michael would do a decent job of looking into why this speed improved rather than just posting some meaningless benchmarks that'd be great.

    Then again, that would be expecting him to do work which much be a scary thought.
    Anyone can simply reproduce the tests I have done and investigate further. Everything is automated down to the performance Git bisecting. But I don't have the time to run all of that when I have other things to benchmark and other work.

  5. #5
    Join Date
    Sep 2012
    Posts
    5

    Default

    It would be nice if this would also mean a noticeable performance boost when using kvm virtualization, since 3d spice is still a long way down the line

  6. #6
    Join Date
    Oct 2012
    Location
    Washington State
    Posts
    360

    Default

    Quote Originally Posted by Jonimus View Post
    Now if only Michael would do a decent job of looking into why this speed improved rather than just posting some meaningless benchmarks that'd be great.

    Then again, that would be expecting him to do work which much be a scary thought.
    I'd start with studying the LLVM Pipeline and R600 Target branch. You'll have your answers with the quality of architecture that is throughout LLVM/Clang/LLDB versus the legacy architecture of GCC.

  7. #7
    Join Date
    Jul 2009
    Posts
    220

    Default

    will the new kaveri APUs have the same numbers for LLVM-Pipe as for OpenGL then? or is it still too far away, or actually not wanted..? (thinking of hUMA memory architecture)
    Does anyone know anything?

  8. #8
    Join Date
    Dec 2011
    Posts
    1,931

    Default Any room left for more improvements?

    Nice improvements with many benchmarks now twice as fast!

    Is there any room left for further improvements to LLVMpipe?
    What is LLVMpipe missing? What could be better? How could it be better?

  9. #9
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,280

    Default

    Quote Originally Posted by jakubo View Post
    will the new kaveri APUs have the same numbers for LLVM-Pipe as for OpenGL then? or is it still too far away, or actually not wanted..? (thinking of hUMA memory architecture)
    Does anyone know anything?
    Guessing you mean "OpenGL on llvmpipe (effectively a graphics driver for CPU) on the Kaveri CPU vs OpenGL on radeonsi (graphics driver for GPU) on the kaveri GPU" ? If so then the GPU path would still be much faster because of the inherent performance difference between GPU and CPU (think 50:1 when doing work that is a good fit for highly parallel hardware).

    The big deal with HUMA is the ability for CPU and GPU to share virtual memory so that applications which *don't* fit cleanly onto highly parallel hardware can make use of both CPU and GPU without the usual overheads.

    One obvious question is "what if llvmpipe were ported to run on the GPU ?". It still wouldn't be as fast as using the graphics pipes because a GPU still has a number of highly optimized fixed function blocks (texture engines, depth/colour operations, rasterizers etc..) and because llvmpipe probably wouldn't scale well to the hundreds or thousands of threads a GPU thrives on.

  10. #10
    Join Date
    Jul 2009
    Posts
    220

    Default

    Quote Originally Posted by bridgman View Post
    Guessing you mean "OpenGL on llvmpipe (effectively a graphics driver for CPU) on the Kaveri CPU vs OpenGL on radeonsi (graphics driver for GPU) on the kaveri GPU" ? If so then the GPU path would still be much faster because of the inherent performance difference between GPU and CPU (think 50:1 when doing work that is a good fit for highly parallel hardware).

    The big deal with HUMA is the ability for CPU and GPU to share virtual memory so that applications which *don't* fit cleanly onto highly parallel hardware can make use of both CPU and GPU without the usual overheads.

    One obvious question is "what if llvmpipe were ported to run on the GPU ?". It still wouldn't be as fast as using the graphics pipes because a GPU still has a number of highly optimized fixed function blocks (texture engines, depth/colour operations, rasterizers etc..) and because llvmpipe probably wouldn't scale well to the hundreds or thousands of threads a GPU thrives on.
    so if LLVM would be mature enough to take advantage of those highly optimized fixed functions. would there be a difference? wouldnt OpenCL be obsolete?

Posting Permissions

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