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. Samsung 850 EVO SSD Linux Benchmarks
  2. Kubuntu 15.04 Is Turning Out Quite Nice, Good Way To Try Out The Latest KDE
  3. 5-Way Linux Distribution Comparison On The Core i3 NUC
  4. OCZ ARC 100 Linux SSD Benchmarks
  5. Lenovo ThinkPad X1 Carbon Works Great As A Linux Ultrabook
  6. Transcend SSD370 256GB
Latest Linux News
  1. Kdenlive Ported To Qt5/KF5, Coming To KDE Applications 15.04
  2. HTC & Valve Partnered Up For The Steam VR Headset
  3. 8cc: A Small C11 Compiler
  4. Not Everyone Likes The Possible "VULKAN" Name For Next-Gen OpenGL
  5. The Binary Blobs Making Up Coreboot
  6. Linux 4.0 & LLVM vs. GCC Yielded Much Interest This Month
  7. XBMC/Kodi 15.0 Alpha 1 Released
  8. Xfce 4.12 Released After Nearly Three Years Of Work
  9. The Khronos Group Filed A Trademark On "Vulkan" API
  10. Mozilla Thunderbird Adoption Climbs, Thunderbird 38 In May
Most Viewed News This Week
  1. Linux 4.0-RC1 Tagged, Linux 4.0 Will Bring Many Notable Improvements
  2. Screenshots Of The GNOME 3.16 Changes
  3. More Proof That Allwinner Is Violating The GPL
  4. The Tremendous Features Of Fedora 22
  5. Krita 2.9 Released, Their Biggest Release Ever
  6. Linux 4.0 Doesn't Have The Weirdest Codename
  7. A Single UEFI Executable With The Linux Kernel, Initrd & Command Line
  8. Canonical Comes Up With Its Own FUSE Filesystem For Linux Containers
%%CLICK_URL_UNESC%%