Announcement

Collapse
No announcement yet.

Gallium3D LLVMpipe Still Needs A Very Fast CPU

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

  • Gallium3D LLVMpipe Still Needs A Very Fast CPU

    Phoronix: Gallium3D LLVMpipe Still Needs A Very Fast CPU

    The Gallium3D LLVMpipe driver is capable of running some old OpenGL games on the CPU at low resolutions assuming your processor is powerful enough...

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

  • #2
    ??

    i can t see any interess to use cpu as gpu in games

    Comment


    • #3
      Originally posted by Andrecorreia View Post
      i can t see any interess to use cpu as gpu in games
      I agree completely. The point in LLVMpipe is so the compositor will still work, therefore it's the compositor/window manager that should be benchmarked.

      Comment


      • #4
        It also serves as a fallback if something isn't implemented on a particular graphics driver.

        Comment


        • #5
          Originally posted by duby229 View Post
          I agree completely. The point in LLVMpipe is so the compositor will still work, therefore it's the compositor/window manager that should be benchmarked.
          Yea, although the results would typically not be that different. If you need to resort to LLVMpipe, then you're probably using an Atom or so, and you just can't do anything with their processors anyway.

          Comment


          • #6
            I think you should test with a many-core CPU p.e. with a 16-core Opteron.
            GPU-s use many cores too.

            Comment


            • #7
              well llvmpipe can improve but never enough to replace an GPU unless in the future CPU suffer a very nasty redesign. that said the function of LLVM is to be the last resort and keep the compositor running not play games for that you have an GPU(that failed tho).

              an additional benefits come from specific scenarios where you need a very simple compositor and an specialized GUI and you don't wanna waste power on an GPU[industrial systems, embedded, micro servers, gadgets,etc] and for this is magnitudes faster than the previous softpipe

              Comment


              • #8
                Originally posted by ua=42 View Post
                It also serves as a fallback if something isn't implemented on a particular graphics driver.
                No it does not! I would provide a source, but showing that something is true for alle cases is hard But it should be easy to prove me wrong in case there is such a fallback.

                Comment


                • #9
                  Originally posted by droste View Post
                  No it does not! I would provide a source, but showing that something is true for alle cases is hard But it should be easy to prove me wrong in case there is such a fallback.
                  well if an operation fail it do fallback to software rendering which translate into softpipe or llvmpipe[you choose the backend] and as far as i remember AMD use it as fallback for hardware that lacks vertex shaders like the IGP 4200 series[is in an post from couple of years ago, use forum search]

                  Comment


                  • #10
                    Originally posted by jrch2k8 View Post
                    well if an operation fail it do fallback to software rendering which translate into softpipe or llvmpipe[you choose the backend] and as far as i remember AMD use it as fallback for hardware that lacks vertex shaders like the IGP 4200 series[is in an post from couple of years ago, use forum search]
                    There's no automatic fallback like you are implying. It happens that certain drivers on really weak hardware (like that 4200, or the i915g intel driver) can specifically code in their driver to use the draw module for vertex shaders, because the hardware doesn't support that natively. But it's not like anyone running radeon si drivers will get a llvmpipe fallback because they hit some path that hasn't been implemented in the new drivers yet. It doesn't work like that.

                    Comment


                    • #11
                      Well...

                      Originally posted by Michael Larabel View Post
                      Phoronix: Gallium3D LLVMpipe Still Needs A Very Fast CPU

                      Well, no shit sherlock. You aren't supposed to use this to render your desktop, you are supposed to use it for render accuracy and new OGL component testing. CPUs have and will always be shitty GPUs, just as for many tasks GPUs are shitty CPUs.
                      Last edited by Kivada; 08-23-2013, 10:56 PM.

                      Comment


                      • #12
                        Originally posted by smitty3268 View Post
                        There's no automatic fallback like you are implying. It happens that certain drivers on really weak hardware (like that 4200, or the i915g intel driver) can specifically code in their driver to use the draw module for vertex shaders, because the hardware doesn't support that natively. But it's not like anyone running radeon si drivers will get a llvmpipe fallback because they hit some path that hasn't been implemented in the new drivers yet. It doesn't work like that.
                        well we agree in the 4200/i915 cases but i am fairly sure the software fallbacks are there and is been discussed in a fair amount of threads now from which im not sure if this happens automatically[less likely] or only certain paths in the driver for certain conditions are hardcoded to fallback to software if any error is detected[at least until hardware get the feature] but someone closer to mesa could explain more deeply how the fallback is done and what are the heuristics for it.

                        of course if llvm support gl 4.4 and radeonsi support gl 2.1, all the llvm fallbacks will be gl 2.1 calls since the driver never announced opengl 4.4 to the application nor the driver will magically assume add new functionality outside its proper context unless is hardcoded to do so, in this we agree too

                        Comment


                        • #13
                          Originally posted by jrch2k8 View Post
                          but i am fairly sure the software fallbacks are there and is been discussed in a fair amount of threads now from which im not sure if this happens automatically[less likely] or only certain paths in the driver for certain conditions are hardcoded to fallback to software if any error is detected[at least until hardware get the feature] but someone closer to mesa could explain more deeply how the fallback is done and what are the heuristics for it.
                          Like i said, this doesn't happen, at least not on modern hardware and drivers.

                          Post proof if you believe otherwise - and no, comments in this forum don't count unless they are by a Mesa developer.

                          Comment


                          • #14
                            Originally posted by smitty3268 View Post
                            Like i said, this doesn't happen, at least not on modern hardware and drivers.

                            Post proof if you believe otherwise - and no, comments in this forum don't count unless they are by a Mesa developer.
                            Now imagine using a small cluster of Epiphany-IV processors !
                            http://en.wikipedia.org/wiki/Adapteva

                            Comment


                            • #15
                              Wayland

                              Does LLVMpipe work with Wayland?

                              Comment

                              Working...
                              X