Questions Arise Over NVIDIA's Fence Sync Support

[phoronix]

Phoronix: Questions Arise Over NVIDIA's Fence Sync Support

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...

http://www.phoronix.com/vr.php?view=ODg3NA

[oneman]

yay!! I knew we could all just get abong!!

[pingufunkybeat]

What does Fence Sync do?

Can anybody give some background?

[rohcQaH]

What does Fence Sync do?

It provides some needed syncing for nvidia that everyone else is doing in the kernel driver.
The claim is that nvidia's driver lacks the needed meta-information in kernel-space to implement this kind of synchronisation there, thus needs a different solution.

This solution has a few side-effects though:
- it adds complexity and possibly another server round trip, even on drivers where it's not needed. It hasn't been tested yet how much performance this will cost in real-life situations.
- it requires changes to all compositing managers to call the new functions at the correct times (which would include additional logic to detect whether the functions are supported by the X server and everything).

On the other hand, the claim is that this sync API allows some other cool stuff(tm) on all drivers once implemented. The posts haven't been to clear about what exactly this cool stuff(tm) actually is, though.