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. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  2. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  3. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
  4. Sumo's Omni Gets Reloaded
Latest Linux Articles
  1. 20-Way Radeon Comparison With Open-Source Graphics For Steam On Linux Gaming
  2. Preview: OS X 10.10 Yosemite vs. Ubuntu Linux GPU Performance
  3. Radeon Graphics Yield Mixed Results With Linux 3.17 Kernel
  4. AMD's RadeonSI Driver Sped Up A Lot This Summer
Latest Linux News
  1. Metro 2033 Redux Will Hopefully Hit Linux Real Soon
  2. New Virtual Monitor Software Might End Up On Linux
  3. Company of Heroes 2 Might Be Coming Out For Linux
  4. NIR Still Being Discussed For Mesa, LLVM Gets Brought Up Again
  5. Plasma Active Is Mostly Ported To KDE Frameworks 5
  6. Google Chrome 37 Brings Many Security Fixes
  7. MenuetOS Updated With SMP Threads & Onscreen Keyboard
  8. Mesa Has A New Release Manager
  9. Enlightenment E19 Lands Its New Wayland Compositor Code
  10. Nouveau Turns Into A Mess In Latest Linux 3.17 + Mesa 10.3-dev Tests
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. [DB] BIOS - ACPI - data collecting
  3. It's Now Possible To Play Netflix Natively On Linux Without Wine Plug-Ins
  4. AMD Releases UVD Video Decode Support For R600 GPUs
  5. Announcing radeontop, a tool for viewing the GPU usage
  6. Users defect to Linux as OpenBSD removes Lynx from base system
  7. Chinese People Try To Patent Wine On ARM
  8. American Citizens running AMOK for food stamps