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 Linux Hardware Reviews
  1. A Walkthrough Of The New 32 System Open-Source Linux Benchmarking Test Farm
  2. Habey MITX-6771: Mini-ITX Board With Quad-Core J1900 Bay Trail
  3. OCZ Vector 150 SSD On Linux
  4. Noctua i4 CPU Cooler: Great For Cooling High-End LGA-2011v3 CPUs
Latest Linux Articles
  1. 17-Way Linux Graphics Card Comparison With Civilization Beyond Earth
  2. AMD Kaveri: Open-Source Radeon Gallium3D vs. Catalyst 14.12 Omega Driver
  3. 12-Way AMD Catalyst 14.12 vs. NVIDIA 346 Series Linux GPU Comparison
  4. AMD Catalyst 14.12 Omega Driver Brings Mixed Results For Linux Users
Latest Linux News
  1. Fedora Doesn't Yet Enable F2FS File-System Support
  2. XZ 5.2 Adds New Multi-Threaded Options
  3. Intel 2.99.917 X.Org Driver Released, 3.0 Release Finally Near
  4. Server-Side XCB Is Being Discussed For The X.Org Server
  5. Adreno A4xx Rendering With Freedreno Takes Shape
  6. Linux 3.19-rc1 Kernel Released Ahead Of Schedule
  7. X.Org Server 1.16.3 Released To Fix Security Issues
  8. Linux 3.19 Merge Window Closes Ahead Of Schedule
  9. MIPS R6 Architecture Now Supported By GCC
  10. LowRISC To Feature Tagged Memory & Minion Cores
Latest Forum Discussions
  1. FPS capped on Linux (AMD fglrx drivers)
  2. Maker3D - create your 3D RPG
  3. Need some hand holding with upgrading xserver
  4. Speeding up systemd networking service
  5. Major Performance Breakthrough Discovered For Intel's Mesa Driver
  6. Looking for an nVidia GPU, but not sure how well they are supported.
  7. Are there an app using HSA ?
  8. The New SuperTuxKart Looks Better, But Can Cause GPU/Driver Problems