Page 1 of 4 123 ... LastLast
Results 1 to 10 of 38

Thread: GPU Software Fallbacks: What's Better?

  1. #1
    Join Date
    Jan 2007
    Posts
    15,636

    Default 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. #2
    Join Date
    Feb 2008
    Posts
    1,356

    Default

    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 .

  3. #3
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    993

    Default

    Fallbacks are garbage, especially on such a slow cpu. They are just a waste of time.

  4. #4
    Join Date
    Sep 2011
    Posts
    708

    Default

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

  5. #5
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,571

    Default

    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.

  6. #6
    Join Date
    Feb 2008
    Posts
    1,356

    Default

    Quote 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

  7. #7
    Join Date
    Jun 2011
    Posts
    1,107

    Default

    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.

  8. #8
    Join Date
    May 2011
    Posts
    59

    Default

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

  9. #9
    Join Date
    Jun 2006
    Location
    Portugal
    Posts
    543

    Default

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

  10. #10
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,571

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •