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

OpenCL Gallium3D State Tracker Merged Into Mesa

Mesa

Published on 11 May 2012 09:41 AM EDT
Written by Michael Larabel in Mesa
15 Comments

While the OpenCL enablement process for the open-source GPU drivers isn't over yet, there's a big accomplishment today: the "Clover" OpenCL state tracker for Gallium3D has finally been merged to Mesa Git master.

The Clover (OpenCL over Gallium3D) state tracker has been around for about three years but only in the past year has the enablement of this GPGPU language finally taken off within Mesa/Gallium3D. Thanks to Google Summer of Code, an X.Org EVoC project, work by AMD, and other efforts, OpenCL is finally coming together for the Gallium3D drivers -- almost four years after the OpenCL 1.0 specification was ratified.

It was back in February that the Nouveau driver could basically handle OpenCL compute using out-of-tree code. This was demonstrated at FOSDEM. One month later was when Radeon Gallium3D sort of began to work for OpenCL.

In late March was when Francisco Jerez began work to merge the Gallium3D compute infrastructure. Various bits have been merged already, but today the third step has finally been realized: importing the OpenCL state tracker.

With this commit just under 15,000 lines of code was introduced as the OpenCL "Clover" state tracker was merged. (This comes after merging other Gallium3D compute plumbing bits and other prerequisites.)

While this has happened, the Nouveau and Radeon driver implementations for this still need to be merged to master. At least though they're getting very close with the R600 LLVM back-end having been merged.

Nice job to the developers involved and interesting times are ahead!

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. MSI X99S SLI PLUS On Linux
  2. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  3. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  4. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
Latest Linux Articles
  1. RunAbove: A POWER8 Compute Cloud With Offerings Up To 176 Threads
  2. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  3. Ubuntu 14.10 XMir System Compositor Benchmarks
  4. Btrfs RAID HDD Testing On Ubuntu Linux 14.10
Latest Linux News
  1. Fedora 21 Beta & Final Release Slip Further
  2. Mesa 10.3.2 Has A Couple Bug-Fixes
  3. RadeonSI/R600g HyperZ Support Gets Turned Back On
  4. openSUSE Factory & Tumbleweed Are Merging
  5. More Fedora Delays: Fedora 21 Beta Slips
  6. Mono Brings C# To The Unreal Engine 4
  7. Coreboot Now Has Support For Intel Broadwell Hardware
  8. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  9. GTK+ Lands Experimental Backend For Mir Display Server
  10. Ubuntu 14.10 Officially Released
Latest Forum Discussions
  1. HOPE: The Ease Of Python With The Speed Of C++
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  4. Linux hacker compares Solaris kernel code:
  5. Advertisements On Phoronix
  6. Users/Developers Threatening Fork Of Debian GNU/Linux
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. Proof that strlcpy is un-needed