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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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.
          Test signature

          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 .

            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.
                    Test signature

                    Comment

                    Working...
                    X