Announcement

Collapse
No announcement yet.

LLVMpipe's Geometry Processing Pipeline Kicks

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

  • LLVMpipe's Geometry Processing Pipeline Kicks

    Phoronix: LLVMpipe's Geometry Processing Pipeline Kicks

    A month ago we talked about Gallium3D's LLVMpipe performing well and providing a much better software rasterizer than what is available with classic Mesa. Using LLVMpipe and a modest CPU for acceleration, the OpenArena was just about playable without any GPU assistance. Now a month later LLVMpipe is becoming a even more serious performer. LLVMpipe now is able to tap into the new geometry processing pipeline and it's causing some major performance gains...

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

  • #2
    I can't pretend to understand much of what this actually does, but it is certainly good news.

    Can other drivers leverage this? So, will r300g be faster thanks to this?

    Comment


    • #3
      Originally posted by HokTar View Post
      Can other drivers leverage this? So, will r300g be faster thanks to this?
      Only software drawing (the softpipe driver) has been improved, r300g shouldn't use the CPU for rendering.

      As I understand it, softpipe is written mainly for debugging, to compare rendering results (thus finding driver bugs) and to temporarily fill in unfinished functionality on new drivers. I don't think the end user is supposed to use it.

      Comment


      • #4
        Afaik LLVM won't be used for r300g.

        Comment


        • #5
          how well does this scale on multicore cpus?
          is llvm used as a backend for the gallium layer, which is a backend for mesa?
          cpu -> llvm -> gallium3d -> mesa

          Comment


          • #6
            Thinking about running some LLVMpipe tests this week or next.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #7
              Originally posted by Michael View Post
              Thinking about running some LLVMpipe tests this week or next.
              This would be great

              Comment


              • #8
                The good thing is ability to compile llvmpipe with dri state tracker, so this produces swrastg_dri.so, and replacing swrast_dri.so with this file gives u good boost on software rendering.

                Comment


                • #9
                  Typo...

                  LVMpipe leverages the Low-Level Virtal...

                  Comment


                  • #10
                    Could perhaps be handy for things like WebGL on Netbooks (without Ion, Poulsbo etc.)?

                    Comment


                    • #11
                      Won't r300g utilize this for the parts of OpenGL 3 that require unimplemented functionality?

                      Comment


                      • #12
                        AFAIK the main place this can affect hardware drivers is when running on integrated GPUs which don't have vertex processing (TCL) hardware, eg rs4xx and rs6xx. The previous software TCL code was *much* slower than the corresponding code in fglrx; this new code should bring that aspect of open source driver performance up to roughly fglrx levels.

                        There were some problems running 300g on rs4xx/rs6xx parts in the past (ie it didn't work), not sure of current status so some additional work may be needed before this becomes usable on those IGP parts.

                        re: OpenGL 3 and higher on 3xx-5xx parts, I'm not sure what the current thinking is. My expectation had been that only GL 2.x would be exposed (so the app would use code paths which were fully hardware implemented) but I don't know if anyone has looked hard at the implications of trying to run higher levels of GL on those parts.

                        Comment


                        • #13
                          Originally posted by bridgman View Post
                          AFAIK the main place this can affect hardware drivers is when running on integrated GPUs which don't have vertex processing (TCL) hardware, eg rs4xx and rs6xx.
                          And intel chips, if they ever get gallium drivers running.

                          Comment


                          • #14
                            Can a state tracker use both hardware and softpipe?

                            Comment


                            • #15
                              I believe the core functions of this code was added to a shared module that both the softpipe and hardware drivers can access. So it's not so much that both the hardware and softpipe are being used at the same time, but rather just a shared piece of code that any driver, including softpipe, can access.

                              Comment

                              Working...
                              X