Announcement

Collapse
No announcement yet.

Gallium3D / LLVMpipe With LLVM 2.8

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

  • #11
    lolz. Michael, 640 x 4800 is a serious business resolution that you shouldn't be fucking with. Proof-reading ma man .

    Comment


    • #12
      so.. gallium would have GPU accelerated code also? or only CPU ?

      Comment


      • #13
        Originally posted by L33F3R View Post
        lolz. Michael, 640 x 4800 is a serious business resolution that you shouldn't be fucking with. Proof-reading ma man .
        That resolution is perfect for projecting onto a skyscraper.

        Comment


        • #14
          Originally posted by NomadDemon View Post
          so.. gallium would have GPU accelerated code also? or only CPU ?
          It has both. The CPU path is useful for finding bugs in the GPU path.

          Comment


          • #15
            Originally posted by NomadDemon View Post
            so.. gallium would have GPU accelerated code also? or only CPU ?
            Gallium3D is a driver framework which allows both software (CPU) and hardware (GPU) accelerated drivers. Softpipe and llvmpipe are software drivers, the rest are GPU-accelerated drivers.
            Test signature

            Comment


            • #16
              The LLVMpipe rasterizer scales very well with core count doesn't it? On a 6-core cpu one should expect better performance right?

              Comment


              • #17
                It should scale very well with the number of cores, yes, but core count, raw MHz and memory performance all play a role.

                Comment


                • #18
                  Originally posted by pingufunkybeat View Post
                  Every sane GL library needs a software fallback for the case that the driver does not implement hardware acceleration for particular functionality. In that case, the CPU is used to perform such operations. It will be considerably slower, but at least it will render correctly, which is what the library is supposed to do.
                  Eh, software fallbacks are an OpenGL developer's worst nightmare. The API should report an error when you try to use an unsupported feature, so you can fallback to a simpler implementation or bail out completely.

                  Software fallbacks are nasty because you don't know when they are going to trigger and there's little you can do when they do trigger. You can rest assured that no user will appreciate a 2fps rendering, they'll just say e.g. Google Earth sucks and delete it from their system.

                  Fortunately, the situation is much better nowadays where we have more capable hardware and an OpenGL that is better-aligned with hardware capabilities. This used to suck much more back around the R200/R300 era when you could hit shader limits trivially (and sometimes randomly).

                  Comment


                  • #19
                    BlackStar, just shut the fuck up. I'm not even going to make any effort defending software fallback. If a user doesn't like 2fps Vs. a blank screen the problem is simply between keyboard and chair. Nobody who is able to influence the Gallium3D code will think otherwise. Noobs be noobs.

                    Comment


                    • #20
                      V!ncent, the issue here is that many applications include code paths for different levels of GL support, so in most cases exposing a lower level of GL support that is fully HW accelerated will give a better user experience than exposing the higher level of GL support but with a few software fallbacks.
                      Test signature

                      Comment

                      Working...
                      X