Announcement

Collapse
No announcement yet.

LLVMpipe Still Is Slow At Running OpenGL On The CPU

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • LLVMpipe Still Is Slow At Running OpenGL On The CPU

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

    Two months ago we published our initial benchmarks of LLVMpipe, the Gallium3D driver that accelerated commands on the CPU rather than any GPU and unlike other Linux software rasterizers is much faster due to leveraging LLVM (the Low-Level Virtual Machine) on the back-end. Since then we have published new ATI Gallium3D driver benchmarks and yesterday put out Nouveau Gallium3D driver benchmarks, so today we are providing updated LLVMpipe driver results to show how well Gallium3D's LLVMpipe driver can accelerate your OpenGL games with a modern processor.

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

  • #2
    Should've included the Mesa renderer as well, to see if things have improved there.

    Comment


    • #3
      Include Mesa software rasterizer

      These results only matter in the context of the Mesa software rasterizer. It doesn't matter how LLVMpipe compares with GPU acceleration, only software. LLVMpipe will always be slower than a GPU accelerated path.

      Comment


      • #4
        Mesa software rasterizer numbers should be out soon, using a different system for more tests.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          Originally posted by Michael View Post
          Mesa software rasterizer numbers should be out soon, using a different system for more tests.
          You should run on the same system for an apples to apples comparison.

          Comment


          • #6
            Originally posted by kjeremy View Post
            You should run on the same system for an apples to apples comparison.
            It will be an apples to apples comparison as the LLVMpipe is being repeated on that other system.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by kjeremy View Post
              These results only matter in the context of the Mesa software rasterizer. It doesn't matter how LLVMpipe compares with GPU acceleration, only software. LLVMpipe will always be slower than a GPU accelerated path.
              I wonder... How much will LLVMpipe's performance be boosted by multi-threading? CPU's are faster than GPU's with single threading. The reason GPU's are faster is because of the extreme parallelization. CPU's are getting more and more cores. Maybe Intel/AMD CPU's will come a lot closer to GPU's in the future? CPU's cut latency a lot, but memory is nevertheless still a problem. The entire cashe design will need a lot of love (not just one big chunck in one place).

              Comment


              • #8
                Originally posted by Michael View Post
                Mesa software rasterizer numbers should be out soon, using a different system for more tests.
                should've waited for that, then...

                Comment


                • #9
                  llvmpipe uses or will use multi-threading, it might have been already implemented to some extent, not sure.

                  I believe llvmpipe should be good for playing rather simpler games with the resolution 640x480, not higher. Even if it was 10 times slower than current GPUs (which is nearly impossible considering the number of GFLOPs on CPUs compared to GPUs), it would be the best software rasterizer out there. I think beating some older Intel IGPs in performance is feasible.

                  I doubt it will be useful for Compiz, I mean you won't be able to use your CPU for something useful when moving a window, really.

                  Comment


                  • #10
                    well i posted this already some time ago, swrast in gallium handle kwin composite flawlessly and a max cpu usage in my system of 8%, ok i have a big cpu but is efficient enough for any modern cpu to provide a nice confortable composited experience.

                    so no it doesnt need 8 core to render a composited desktop or anything like that lol, first test it and the post facts, dont just assume

                    about gaming michael, well like someone said before the gflops diff is too big to even compare it to a gpu, so dont expect swrast to beat a gpu driver anytime in this century(unless something really big happens in the cpu sector).

                    so being realistic swrast is a great testing plataform, a life saver boat when your gpu is unsupported but you still want at least composite and nice video performance, IS NOT the ultimate gpu killer and is not meant that way.

                    now i admit it still can improve a lot but compare it with a gpu accelerated driver is not realistic, ok i admit is cool see something above 3fps using a cpu only, but you cannot say it sucks cuz noveau in a 9800gtx is way faster LOL, in any case compare it against an intel crappy igp

                    btw push 28 fps cpu only is quite an achievement

                    Comment


                    • #11
                      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

                      Comment


                      • #12
                        Are there any plans to use any parts of LLVMpipe alongside the GPU drivers? For example, to move calculations to the cpu if the gpu is overloaded, or if there are things a particular cpu does more efficiently than the GPU?

                        I guess more importantly, are there any benefits to such an approach?

                        Comment


                        • #13
                          I believe parts of LLVMpipe are being used already in cases where the GPU does not have vertex shader hardware.

                          Dynamic load balancing (shifting driver work between CPU and GPU depending on the relative performance of the two) is a much bigger issue because getting non-sucky performance requires that the CPU have all of its data in system memory while the GPU needs all of its data to be in video memory.

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            I believe parts of LLVMpipe are being used already in cases where the GPU does not have vertex shader hardware.

                            Dynamic load balancing (shifting driver work between CPU and GPU depending on the relative performance of the two) is a much bigger issue because getting non-sucky performance requires that the CPU have all of its data in system memory while the GPU needs all of its data to be in video memory.
                            I don't know if this is stupid, but it seems like a back and forth latency problem. Can you keep the memory both in system memory and video memory and have that sync all the time? Maybe them you would not need to do the back and forth in a crucial moment in time?

                            *ducks and runs*

                            Comment


                            • #15
                              Sure, you just turn on the "magic pixie dust" bit in the hardware

                              Seriously, dealing with latency between different memory subsystems (with the associated need for change detection and synchronization) is probably the biggest single challenge when implementing highly parallel systems. It doesn't mean that an easy solution does not exist but it hasn't been found yet.

                              Read up on "cache snooping", for example.

                              Comment

                              Working...
                              X