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

Having SNAppy Intel 2D Acceleration In 2012

Michael Larabel

Published on 31 January 2012
Written by Michael Larabel
Page 1 of 8 - 8 Comments

Here's a new look at Intel's Sandy Bridge New Acceleration (SNA) architecture within their DDX graphics driver. Testing in this article was done across three systems (mobile and desktop class Sandy Bridge hardware as well as an Ironlake system) seeing how well the latest code is performing in an effort to provide a better Intel 2D experience.

Sandy Bridge New Acceleration, which was designed by Chris Wilson at Intel's Open-Source Technology Center to be a crazy fast acceleration architecture and formally introduced in June of 2011, has been making much progress. In fact, nearly all of the activity still going on within the xf86-video-intel DDX driver is SNA-related. There isn't too much fun left to be had within the Intel X.Org driver with most of the interesting work going into the Intel DRM kernel driver (and Mesa for the 3D work).

SNA has turned into Chris Wilson's personal vendetta within the Intel Linux graphics driver. SNA-related commits are still happening almost daily; there's been almost 100 SNA commits in the past week and about 350 SNA commits since the start of 2012. While much activity has been happening around Sandy Bridge New Acceleration, and in most cases it's significantly faster than the stock UXA (a gutted EXA with GEM handling) for 2D acceleration, it's still not the default acceleration architecture. SNA does have accelerated back-ends for older generations of Intel integrated graphics, but occasionally with all of this work happening there are regressions and other issues that come up related to SNA.

As far as whether SNA will ever be the default, when talking about it with Keith Packard at XDC2011 Chicago he made it sound like it was unlikely to make the switch from the stock UXA mode. When asking Chris Wilson about the future of SNA this past weekend and whether it would become the default, he said, "At this moment in time, I have no idea."

Chris went on to say, "I just hope the future where we have a DDX that is never slower or more power hungry than simply using the CPU, ala shadowfb, and is truly competitive with not only our Windows colleagues but with competing chipsets arrives sooner rather than later." It's a nice mission, so let's see how SNA is running today.

<< Previous Page
1
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. Linux hacker compares Solaris kernel code:
  2. Advertisements On Phoronix
  3. HOPE: The Ease Of Python With The Speed Of C++
  4. Updated and Optimized Ubuntu Free Graphics Drivers
  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