1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

GPU Software Fallbacks: What's Better?

Mesa

Published on 22 June 2014 01:09 PM EDT
Written by Michael Larabel in Mesa
37 Comments

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.

As covered a few hours ago, Eric already made a lot of progress with his DRM+Gallium3D code for his first week of being a Broadcom employee. The ex-Intel developer said his reason for going with a Gallium3D driver initially was to prototype the driver quicker and get things up and running easier than developing a complete classic Mesa driver. While Gallium3D gets things up and running faster, he said he wanted to switch to a classic driver model eventually so he could take advantage of Mesa's "swrast" software rasterizer fallbacks, etc to make up for the Broadcom VC4 GPU's shortcomings.

This week when it was mentioned of looking to ultimately switch from Gallium3D to classic Mesa to use software fallbacks, of course that sparked a discussion of mixed opinions among upstream Mesa developers. That part of the discussion about Mesa/Gallium3D software fall-backs can be found with this mailing list thread.

Marek Olšák quickly chimed in about the i915 Gallium3D code using the Gallium3D Draw module, which can do per-vertex operations on the CPU and for some operations are made faster by LLVM. Among those instructions that can fallback to the CPU with the Gallium3D Draw support include vertex fetching, vertex shaders, geometry shaders, culling and clipping, viewport transformation, primitive translations of point/line/triangle lists, other conversions, generation of point sprite coordinates, and other tasks.

David Airlie also got in on the discussion, "Do we know anywhere swrast fallbacks make sense? like except for conformance testing, You've got an armv6 swrast fallbacks are going to be punishing, I don't even think it has neon extensions."

Eric Anholt responded to Dave by saying, "Yeah, but fallbacks are less punishing than 'my screen is black, what's
going on?!?!' bug reports."

Roland Scheidegger of VMware responded to Anholt's comment that he disagrees: it's better (or just as bad) having a black screen or broken rendering rather than something falling back to the CPU that will run unbearably slow. "I respectfully disagree. You trade 'my screen is black' bug reports (though more than likely just portions of it will be garbage, at least with shader capable hw you should never need to fallback for relatively simple stuff) for 'why does my screen only refresh once every 10 seconds' bug reports. In severity from an end user perspective, they are just as bad. Besides, the full swrast fallbacks rarely work in a fully 'correct' manner (though it may be permitted by GL invariance rules at least in some cases) due to differences in rasterization."

Michel Dänzer added that regardless it shouldn't be hard for Gallium3D to add more entry points to handle Eric's software fallback concerns.

So in the end it will be interesting to see if this Broadcom VC4 driver for the Raspberry Pi and other ARM hardware ends up staying Gallium3D (Eric has already started on the Gallium code) or if it will eventually transform into a classic Mesa driver. 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.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Articles & Reviews
  1. Intel Broadwell: GCC 4.9 vs. LLVM Clang 3.5 Compiler Benchmarks
  2. Ubuntu vs. Fedora Linux On Lenovo's X1 Carbon With Core i7 Broadwell
  3. Ubuntu 15.04 Is The Easy Path To Better Performance On Intel Broadwell
  4. NVIDIA's Latest Maxwell Line-Up Against AMD With Catalyst On Linux
  5. Preliminary Tests Of Intel Sandy Bridge & Ivy Bridge vs. Broadwell
  6. AMD FX-8320E Performance On Linux
Latest Linux News
  1. Linux Benchmarking... Even Faster & A Very Interesting February
  2. Does VirtualBox VM Have Much A Future Left?
  3. HAMMER2 File-System Is Still Slowly Coming Together
  4. The Better Looking Window Decorations For GNOME 3.16
  5. Libinput 0.9 Adds Support For Hovering Fingers On Touchpads
  6. Free Software Foundation Endorses Another (Outdated) Laptop
  7. DNF Plugins Extend The Functionality Of Fedora's Yum Successor
  8. LibreOffice 4.4 Released With Better OOXML Support, UI Improvements
  9. Inkscape 0.91 Goes Through C++ Code Conversion, New Cairo Rendering, OpenMP Filters
  10. New Mesa Patch To Improve CPU-Bound Applications
Most Viewed News This Week
  1. PlayStation 4 System Compiler Support Landing In LLVM
  2. LibreOffice 4.4 Is Coming Soon With New Features
  3. Linux "GHOST" Vulnerability Hits Glibc Systems
  4. Broadwell Linux Ultrabook Running MUCH Cooler Than Haswell
  5. LZHAM 1.0 Lossless Data Compression Codec Released
  6. Linux Users Upset By Chromium's Busted HiDPI Support
  7. Vivaldi: A New Chromium-Powered, Multi-Platform Browser
  8. LLVM Adds Options To Do Fuzz Testing