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

AMD Lands OpenMAX State Tracker In Mesa Gallium3D

Mesa

Published on 06 February 2014 11:38 AM EST
Written by Michael Larabel in Mesa
62 Comments

The OpenMAX state tracker has appeared within Gallium3D in Mesa for another means of exposing MPEG2 and H.264 acceleration on the GPU.

Back in October was when AMD unveiled the OpenMAX Gallium3D state tracker. OpenMAX is a Khronos cross-platform, royalty-free media acceleration API. AMD's Gallium3D driver can take advantage of OpenMAX for H.264 and MPEG4 video acceleration using the Unified Video Decoder (UVD) block. AMD has already been exposing open-source UVD video acceleration via the VDPAU state tracker, but AMD went ahead and developed the OpenMAX state tracker for other purposes -- to eventually support video acceleration and also in providing H.264 Hi10P decode support that wasn't offered in VDPAU.

Earlier this week is when AMD open-sourced VCE video engine code for their newer "CIK" graphics processors. The OpenMAX state tracker will eventually be able to support video encoding/transcoding on the open-source AMD driver stack once those new VCE bits are to land.

With Mesa 10.1 now having been branched and Mesa 10.2 under development, Christian K├Ânig has finally committed the OpenMAX state tracker to mainline Mesa. He wrote, "Featuring a full grown MPEG2 and H264 decoder and a couple of hundred bugs." This state tracker to complement the existing VDPAU support in Gallium3D adds over two thousand lines of new code to Mesa.

On a semi-related note, the Radeon UVD legal notes were updated too, which could potentially impact some with US government restricted rights and now the UVD code is advertising it's subject to export restrictions.

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. openSUSE Factory & Tumbleweed Are Merging
  2. More Fedora Delays: Fedora 21 Beta Slips
  3. Mono Brings C# To The Unreal Engine 4
  4. Coreboot Now Has Support For Intel Broadwell Hardware
  5. Enlightenment's EFL 1.12 Alpha Has Evas GL-DRM Engine, OpenGL ES 1.1 Support
  6. GTK+ Lands Experimental Backend For Mir Display Server
  7. Ubuntu 14.10 Officially Released
  8. Mesa 10.4 Might Re-Enable HyperZ For R600g/RadeonSI
  9. Intel GVT-g GPU Virtualization Moves Closer
  10. GTK+ 3.16 To Bring Several New Features
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