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

Google Pushes More Mesa / Gallium3D Patches

Mesa

Published on 16 June 2013 04:51 PM EDT
Written by Michael Larabel in Mesa
8 Comments

More Mesa / Gallium3D patches out of Google have come about this month for improving the open-source graphics stack.

Google has been using Mesa/Gallium3D drivers for use on their Intel-powered Chromebooks. Google had invested heavily in the Intel Gallium3D driver for use on their older Chromebooks, but now they are starting to push more of their Mesa/Gallium3D changes that have been building up in months past.

Published today on the mailing list by Google's Frank Henigman is an LLVM compiler cache for Gallium3D. "This works (has been in Chrome OS for a while) but only for vertex shaders, not geometry shaders nor llvmpipe...I don't know how much other apps care but it's a big win for Chrome because just opening an empty tab recompiles some shaders and takes hundreds of milliseconds on a low-end chromebook. Revisiting a page with a bunch of shaders is seconds faster....My cache comes in before generating LLVM source however, thus should have bigger savings than can be realized at the LLVM level."

Frank also posted per-texture locking support. This work allows uploading textures from one thread concurrently with drawing in another thread, thus a performance benefit.

Another set of patches out of Google recently allows saving about 1MB per texture with LLVM vertex shaders. This memory-saving work has been in Google's patched Mesa version for a while and is now being submitted for possible upstream inclusion.

Overall, it's good to see Google's continued Mesa involvement and furthering the open-source Linux graphics drivers for Chrome OS.

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. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  2. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  3. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
  4. AMD Radeon R9 285 Tonga Performance On Linux
Latest Linux Articles
  1. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  2. Ubuntu 14.10 XMir System Compositor Benchmarks
  3. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
  4. Ubuntu 14.10 Linux 32-bit vs. 64-bit Performance
Latest Linux News
  1. Mono Brings C# To The Unreal Engine 4
  2. Coreboot Now Has Support For Intel Broadwell Hardware
  3. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  4. GTK+ Lands Experimental Backend For Mir Display Server
  5. Ubuntu 14.10 Officially Released
  6. Mesa 10.4 Might Re-Enable HyperZ For R600g/RadeonSI
  7. Intel GVT-g GPU Virtualization Moves Closer
  8. GTK+ 3.16 To Bring Several New Features
  9. Debian 8.0 Jessie Has Many Multimedia Improvements
  10. What Linux Benchmarks Would You Like To See Next?
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. Linux hacker compares Solaris kernel code:
  3. HOPE: The Ease Of Python With The Speed Of C++
  4. Advertisements On Phoronix
  5. Users/Developers Threatening Fork Of Debian GNU/Linux
  6. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed