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

Questions Arise Over NVIDIA's Fence Sync Support

NVIDIA

Published on 05 December 2010 02:41 PM EST
Written by Michael Larabel in NVIDIA
3 Comments

As reported this morning, RandR 1.4 is now ready for X.Org Server 1.10 after this next xorg-server release's merge window was kept open to allow this work to be finished and land in the Git tree. RandR 1.4 brings per-CRTC pixmaps, sprite transforms, and a new RandR request that will hopefully allow NVIDIA's binary driver to finally support RandR 1.2+ features. While the merge window is kept open for a short period of time, NVIDIA has been trying to put in their Fence Sync support for the X Server. While it looks like these patches will still be accepted, some objections and questions have arose over this open-source contribution by NVIDIA.

Red Hat's Owen Taylor started out by asking about a broad overview on NVIDIA's Fence Sync, seeing as he is the maintainer of Mutter, the GNOME 3.0 compositing window manager that uses Clutter. "There's already a lot of magic voodoo dances around both Damage and Texture-From-Pixmap, what extra incantations does this add to the picture?" Owen further noted, "I can understand each individual step of the magic voodoo dance, but when I go away from the individual problems and come back 6 months later, I have to work it all out again. And there's a strong sense that only particular code paths that actually are in use are tested and anything else probably doesn't work, at least on some drivers."

Once NVIDIA's James Jones gave the usual spiel on the X Fence Sync Support, Owen came back to seek other clarifications and say, "It worries me to see a pretty complex, somewhat expensive band-aid going in *without* knowing more about that long term picture." Keith Packard then hopped in to say, "The trouble here is that all of the drivers we can look at don't need this to work efficiently, so there's no way to evaluate the design to see if it makes any sense at all. Requiring changes to all compositing managers just to support one driver seems like a failure in design, and it will be fragile as none of it will matter until the compositing manager is run against that driver."

James Jones ended up responding that the technical issues brought up by Owen and Keith were already evaluated and discussed by those developers active on IRC. "For my part, I regret that this work may be seen by some as an NVIDIA-backed attempt to dump functionality only needed by a closed-source driver on an
under-staffed open-source project. That is not my intention, and while the discussion has centered around the one initial application of the changes that currently only benefits our driver, I do think fence objects will be generally useful on all platforms. Further, I'll be around to support this code, answer questions about it, etc, as long as NVIDIA keeps paying me, and probably even if they don't just because I find it interesting...I disagree that this is a failure of design. I always try to strike a balance between the most efficient solution for the end users and the constraints of development and maintenance. And we're used to being the odd man out. We regularly need to provide patches or at least point out bugs in many projects that only happen on our drivers for whatever reason (We support a different set of GL extensions, we accelerate a different set of X render operations, older apps relying on non-compliant SGI weirdness, newer apps relying on non-compliant/undefined DRI/mesa/whatever behaviour, etc.). It's not in our interest to needlessly burden our users, but different isn't necessarily always bad."

Keith Packard though came back with a new proposal for NVIDIA. After stomaching the criticism and it being raised so late (days before the merge window closed and months after the sync fences first came), James prepared a counter offer.

Under this latest offer, the X Fence Sync support would go into X.Org Server 1.10, but then as part of the X.Org Server 1.11 release there would be a new version of X Damage. If not X Server 1.11, even possibly a point release in the 1.10 series. This update would conditional-ize the language and allow time for testing the new DamageSubtractAndTrigger functionality to see whether it adds any significant latency. If DamageSubtractAndTrigger turns out not to be bad, then it would be advertised that compositing window managers could hook into this support. James also challenges an open-source driver to implement the explicit mode in this new extension to see whether it's faster than the status quo while still refraining from any desktop tearing.

In the end, it looks like things will be sorted out and ready for the X.Org Server 1.10 release.

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. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  2. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  3. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
  4. Trying The Configurable 45 Watt TDP With AMD's A10-7800 / A6-7400K
Latest Linux Articles
  1. How Intel Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers
  2. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
  3. Testing For The Latest Linux Kernel Power Regression
  4. The Most Energy Efficient Radeon GPU For AMD Linux Gaming
Latest Linux News
  1. Nouveau X.Org Driver Released With DRI3+Present, Maxwell, GLAMOR
  2. Microsoft & AMD Release C++ AMP Compiler With Linux Support
  3. AMD, Wine & Valve Dominated August For Linux Users
  4. Linux 3.17-rc3 Kernel Released Back On Schedule
  5. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  6. Mesa 10.3 RC2 Arrives Via Its New Release Manager
  7. Ubuntu 14.10's Lack Of X.Org Server 1.16 Gets Blamed On AMD
  8. MSI Motherboard BIOS Updating Remains A Pain For Linux Users
  9. See How Your Linux System Performs Against The Latest Intel/AMD CPUs
  10. AMD Steppe Eagle Flys To Coreboot
Latest Forum Discussions
  1. AMD Releases UVD Video Decode Support For R600 GPUs
  2. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  3. SSD seems slow
  4. Is laptop with Intel CPU and AMD dGPU worth buying considering especially AMD Enduro?
  5. Radeon HD5670 and Ubuntu 14.04
  6. Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs
  7. Updated graphics drivers for Ubuntu 12.04 Precise LTS
  8. Catalyst 14.201.1008