Page 4 of 4 FirstFirst ... 234
Results 31 to 37 of 37

Thread: LLVMpipe Still Is Slow At Running OpenGL On The CPU

  1. #31
    Join Date
    Nov 2008
    Posts
    30

    Default

    I wonder if it is possible to combine this renderer with the ATi/Nouveau renderers in a sort of SLI setup for a performance boost?

  2. #32
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by monkeynut View Post
    I wonder if it is possible to combine this renderer with the ATi/Nouveau renderers in a sort of SLI setup for a performance boost?
    You mean use LLVM for the FLOSS drivers? Isn't this already done?

    Or do you mean use LLVMpipe instead of Mesa softpipe to draw unsupported functions on older GPU's?

  3. #33
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    I think Monkeynut means dividing the rendering work between CPU (with LLVMPipe) and GPU (using regular drivers), like Crossfire or SLI but with one real and one "fake" GPU.

    Quick answer is "yes in principle" but because of the overhead associated with splitting and recombining the rendering work it's usually only worth doing if the two renderers are fairly close in performance. In most cases the GPU would be a lot faster than the CPU renderer so the overhead of supporting multiple GPUs would probably match or outweigh the benefit from the additional performance.

    That doesn't make LLVMpipe any less cool, though

  4. #34
    Join Date
    Apr 2010
    Posts
    48

    Default

    Quote Originally Posted by Qaridarium View Post
    only a 48core Opteron 6000 (155gb/s ramspeed)can beat a GPU (hd5870 160gb/s )

    a normal PC do have 5-15gb/s compared to an hd5870 160gb/s its very slow.

    this benchmark only show us this divergence
    That's an oversimplification. CPUs have larger caches than GPUs, so they won't typically need as much memory bandwidth. OTOH, GPUs do have more number crunching power...

    Personally, I would be fine with a software rasterizer, if that would drive my normal desktop use. It should also be much easier to get bugs out of it, since there isn't a multitude of incompatible hardware models to test it against.

  5. #35
    Join Date
    Apr 2010
    Posts
    48

    Default

    Oh, and regarding dynamic load balancing... Couldn't that in principle be used to power down most of the GPU when not needed? Something like Optimus, but CPU+GPU instead of IGP+GPU.

  6. #36
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    460

    Default

    Quote Originally Posted by Otus View Post
    That's an oversimplification. CPUs have larger caches than GPUs, so they won't typically need as much memory bandwidth.
    But 3D rendering memory access is typically horribly non-localised, which is one reason why GPUs don't bother with large caches: adding more processing capacity benefits them more than adding megabytes of cache.

  7. #37
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    But what if the CPU would do just a fraction of the work in a 'SLI' configuration and sync afterwards? Each time the sync function would compare the difference in time spend rendering and adjusts the load dynamically?

Posting Permissions

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