Announcement

Collapse
No announcement yet.

GPU Software Fallbacks: What's Better?

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

  • GPU Software Fallbacks: What's Better?

    Phoronix: GPU Software Fallbacks: What's Better?

    When Eric Anholt announced last week he was developing a Broadcom VC4 DRM plus OpenGL driver he said originally he plans to develop the user-space GL driver as a Gallium3D driver but might later turn it into a classic Mesa driver...

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

  • #2
    As sure to cause some interesting forum discussions this weekend, what do you think is better though in this situation? Namely, in cases where a GPU isn't powerful or properly suited for handling certain operations, is it better for the user to see just broken rendering / black screen or should it still fallback to the CPU where the performance might be horrible and lead to an unplayable gaming experience or sluggish desktop but at least render... Keep in mind the Rapsberry Pi's SoC is a ARMv6 700MHz single core processor.
    If he wants conformant driver than fallbacks, if he wants speed it is obvious . He write driver for hardware with hardware acceleration in mind, so please not make fallbacks, what hardware can do - that is it .

    Comment


    • #3
      Fallbacks are garbage, especially on such a slow cpu. They are just a waste of time.
      ## VGA ##
      AMD: X1950XTX, HD3870, HD5870
      Intel: GMA45, HD3000 (Core i5 2500K)

      Comment


      • #4
        Originally posted by darkbasic View Post
        Fallbacks are garbage, especially on such a slow cpu. They are just a waste of time.
        It should just drop what it can't handle and refuse to start applications that it isn't even slightly compatible with.

        Comment


        • #5
          One of the nice things about mechanical equipment is that it's easy to tell when there's a mismatch between load and capacity. Maybe we could tweak the gfx drivers to send a grinding or whining sound to the audio subsystem when the SW fallbacks kick in so you know that you don't have a bug.

          Comment


          • #6
            Originally posted by bridgman View Post
            One of the nice things about mechanical equipment is that it's easy to tell when there's a mismatch between load and capacity. Maybe we could tweak the gfx drivers to send a grinding or whining sound to the audio subsystem when the SW fallbacks kick in so you know that you don't have a bug.
            . Better to be human voice to tell us whats happens there .

            http://204.178.9.51/tts/speech/6b27e...603fea3c8d.wav

            Comment


            • #7
              I've got to say my vote is for not trying to do things with hardware that it was never designed to do, be that console hardware or the Raspberry Pi. It always ends poorly and you're only supporting delusional idiots who want to think their hardware is way more powerful than it really is, while anybody sane will you know... buy adequate hardware.

              Comment


              • #8
                1. Please use Gallium3D stack only!!!
                2. For RaspberiPI need black screen.
                3. For small functions and fast SSE/AVX/NEON realisations - maybe.

                Comment


                • #9
                  Originally posted by bridgman View Post
                  One of the nice things about mechanical equipment is that it's easy to tell when there's a mismatch between load and capacity. Maybe we could tweak the gfx drivers to send a grinding or whining sound to the audio subsystem when the SW fallbacks kick in so you know that you don't have a bug.
                  Heh, you're kidding, of course, but rendering black and logging somewhere that could then be picked up and reported by the system (e.g. a popup "this software is experiencing issues, please report it to us") would be a better fallback I think.

                  Comment


                  • #10
                    Yep, ideally the stack would be able to pop up something like "this app is using capabilities not supported by the HW so you need to choose between (slow) SW fallbacks or rendering only what the HW can handle".

                    I suspect the reason people still favor software fallbacks is that they are probably a bit less likely to encourage "tweak the app until the rendering looks OK" development which is inevitably followed by "oh crap, the incomplete rendering on HW vendor A is different from the incomplete rendering on HW vendor B". I guess the best would probably be universal agreement that drivers will never use SW fallbacks and apps will always have the ability to fall back to a lower GL level which all HW supports.

                    Comment


                    • #11
                      I have been using GNOME 3 with swrast on Samsung Chromebook for about a year, and it's very usable.
                      After some usage things get stable and somewhat usable. And I've been developing GTK3 stuff in it.

                      Comment


                      • #12
                        Originally posted by Luke_Wolf View Post
                        I've got to say my vote is for not trying to do things with hardware that it was never designed to do, be that console hardware or the Raspberry Pi. It always ends poorly and you're only supporting delusional idiots who want to think their hardware is way more powerful than it really is, while anybody sane will you know... buy adequate hardware.
                        In some cases you might have some operation concerning a not too high amount of vertices that could be offloaded to the GPU using a vertex or geometry shader, and not having software fallbacks in the driver will force all the devs to either handle it with the CPU only, or roll their own software fallback when only one could have been written.

                        It's not really a big deal either way (those cases should be fairly rare), but I don't see the point of not allowing software fallbacks.

                        Comment


                        • #13
                          Originally posted by Luke_Wolf View Post
                          I've got to say my vote is for not trying to do things with hardware that it was never designed to do, be that console hardware or the Raspberry Pi. It always ends poorly and you're only supporting delusional idiots who want to think their hardware is way more powerful than it really is, while anybody sane will you know... buy adequate hardware.
                          That's easy to say. Until you discover that your hardware does everything GL 2.1 requires except these two or three functions and there is a mess of software that runs on GL 2.1 but doesn't support GLES 2. this leaves driver devs with two choices: 1) go find every peice of software using functionality their hardware doesn't support and submit patches to use something else and hope that a) the upstream is willing to take, b) the upstream doesn't accidently (or purposefully break it years later) and c) that the updates for that software all reach distros before their users get super cranky, or 2) use software fallbacks for a few pieces of missing functionality, accept that they are slow and get on with it.

                          Comment


                          • #14
                            Completely black screens are worse than slow performance, but visual mistakes on portions of the screen is better than slow performance.

                            I don't know if it's possible to ever guarantee that you don't completely mess up everything but allow some things to fail for performance, but presumably there is a good tradeoff of features somewhere that you can target which handles all reasonable cases while letting the unreasonable ones fail.

                            Comment


                            • #15
                              Originally posted by crymsonpheonix View Post
                              That's easy to say. Until you discover that your hardware does everything GL 2.1 requires except these two or three functions and there is a mess of software that runs on GL 2.1 but doesn't support GLES 2. this leaves driver devs with two choices: 1) go find every peice of software using functionality their hardware doesn't support and submit patches to use something else and hope that a) the upstream is willing to take, b) the upstream doesn't accidently (or purposefully break it years later) and c) that the updates for that software all reach distros before their users get super cranky, or 2) use software fallbacks for a few pieces of missing functionality, accept that they are slow and get on with it.
                              Everything OpenGL 2.1 requires except for 3 functions... or in short a ~10 year old GPU. No instead of being an insane asshole and trying to force the devs to deal with my hopelessly obsolete hardware, and force the hardware to do things it was never meant to do, I would do the sane thing and buy new hardware.

                              Comment

                              Working...
                              X