Compiz - GL_EXT_x11_sync_object support: testers needed

Question

Please see post below for details.
Last edited by Chazza (2014-06-23 08:10:32)

Answer 1

Okay. I fill in the details, since i am using this patch, have talked with it's author [from nvidia] and have also been in touch with some of the involved compiz devs
Backstory: For months there has been a patch floating around for compiz that implements the GL_EXT_x11_sync_object extension [OpenGL] into compiz. This patch is intended to fix the nvidia refresh issue / possibly other rendering bugs experienced by nvidia users. [although, if using another driver that supports  GL_EXT_x11_sync_object, you would likely benefit too. It adds the ability to use X11 synchronization fences/objects in Compiz [ and nvidia supports this extension ]. The support is about "deep pipelining" not parallelism, the idea is that you have X number of syncs and by the time we fold back to the beginning Y number of syncs should be flushed and thus 'ready', which should avoid any stalling in compiz. As an aside; the mutter devs have also ported this to their framework.
http://www.opengl.org/registry/specs/EX … object.txt
OpenGL Specification wrote:
Synchronization objects added the ability to better coordinate operations between multiple GL command streams. However, it is desirable to have the same level of coordination between GL command streams and external rendering APIs. This extension introduces two new concepts to build upon the synchronization infrastructure provided by ARB_sync:
1) A means to import an X Synchronization Fence object into the GL and use it as a sync object.
2) The concept of a reusable sync object.
The latter is necessary because the import operation is expensive and performing it every time a synchronization point was reached would make the synchronization prohibitively slow.
This extension stops short of allowing the GL to change the state of imported/reusable sync objects, but does not add any language that would prohibit such functionality from being added in a subsequent extension.
Original LP bug report; https://bugs.launchpad.net/compiz/+bug/269904 ...
Why hasn't this patch been integrated into Compiz???
1). Nvidia released the code as MIT, But Canonical requires CLA for contributions [copyright assignment]. Nvidia wouldn't accept those terms.
2). because of #1 - the patch hasn't really had a whole lot of testng / exposure, aside from a single ppa
Now, since we are on Arch - the CLA/Ubuntu thing is not our problem, thus it would be nice to see to get this code into people's hands and tested. We can then report back issues, [hopefully] get any problems sorted out and possibly be able to carry/use the patch, regardless of Canonical not including it in Compiz. [although, having it tested might help it get into compiz/apply some pressure]. So that all being said, we need some testers
TESTING:
I'll provide a compiz package, based on compiz-core-bzr in AUR. Found here; https://www.dropbox.com/s/xryiqlozviwya … src.tar.gz (updated link/package)
There are a few things tester will need to note: First, you will need to start compiz from the commandline for testing [ie: 'compiz --replace ccp' in terminal]
1). I have debug/logging for this patch enabled by default. We need to be able to see if the patch is working or having problems. * but the logging may degrade performance. That being said, you can rebuild the package, without debugging, by commenting/uncommenting the correct patch;
# msg "applying compiz-nvidia-refresh"
# patch -Np1 -i "$srcdir/compiz-nvidia-refresh.patch"
msg "applying compiz-nvidia-refresh_debug.patch - ** DEBUG BUILD - may degrade performance"
patch -Np1 -i "$srcdir/compiz-nvidia-refresh_debug.patch"
2). The number of x11 sync fences/objects is arbitrary, so it is possible, depending on setup that you may require more syncs. I have also dealt with this in the pkgbuild, via line 88;
sed -i 's#NUM_X11_SYNCS = 10#NUM_X11_SYNCS = 16#' "${srcdir}/compiz-nvidia-refresh.patch"
...in the patch the default is 10. I have up'd it to 16. [so has the compiz dev in his package]. So, if you happen to get messages like this;
compiz (opengl) - Info: Initializing sync objects
compiz (opengl) - Warn: We should never wait for a sync -- add more syncs?
compiz (opengl) - Error: Timed out waiting for sync object.
compiz (opengl) - Info: Destroying sync objects
compiz (opengl) - Info: Initializing sync objects
compiz (opengl) - Error: glClientWaitSync failed
compiz (opengl) - Error: Timed out waiting for sync object.
compiz (opengl) - Info: Destroying sync objects
... then you could try increasing the NUM_X11_SYNCS value. Myself, I had to increase them + disable some logging before the patch stabilized for me.
3). You should also open CCSM and do two things; Navigate to "General  Options"->"Focus and Raise Behavior" and disable "auto-raise" [it was causing problems for me/with this patch]. Next, Navigate to "Workarounds" section and disable "force synchronization between X and GLX" [and make sure that "OpenGL" section in CCSM has "X11 Sync Objects" enabled.]
Reporting tests:  You can report back your findings in this thread, but if you are on Launchpad - you can also report back in a couple of places;
nvidia refresh bug - https://bugs.launchpad.net/compiz/+bug/269904
or file a bug against and/or contact Chris from this branch on LP; https://launchpad.net/~townsend/+archiv … fresh-test
otherwise, any issues reported here - I will take to the concerned parties, personally.
If this patched-compiz is stable for you - then you can rebuild it for 'production', rebuilding with the non-debug compiz nvidia-refresh.patch
** but please make sure to report back, before disabling logging.
cheerz
EDIT: Note the below bunch of comments were myself and a user working out some initial issues [one in my packaging], then the next getting compiz + config working for him. My PKGBUILD should be fine now for testing and i have updated the link/instructions/pkgbuild. - sorry for any inconvenience.
Last edited by triplesquarednine (2014-06-24 00:30:59)