Bug 369317

Summary: Kwin crash with gles
Product: [Plasma] kwin Reporter: Andrei Slavoiu <ansla80>
Component: scene-openglAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED UPSTREAM    
Severity: crash CC: stalkerg
Priority: NOR Keywords: drkonqi
Version: 5.7.5   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: epoxy_test.c

Description Andrei Slavoiu 2016-09-25 10:57:34 UTC
Application: kwin_x11 (5.7.5)
 (Compiled from sources)
Qt Version: 5.6.1
Frameworks Version: 5.26.0
Operating System: Linux 4.7.4-gentoo x86_64
Distribution: "Gentoo Base System release 2.3"

-- Information about the crash:
- What I was doing when the application crashed:
Trying to enable compositing

- Custom settings of the application:
The gles USE flag is enabled globaly, that means all QT components as well as kwin are built with gles support. KWIN_COMPOSE is not set. From the looks of .xsession_errors this causes kwin to create a GLES context but treat it as a regular GL one:
OpenGL vendor string:                   X.Org
OpenGL renderer string:                 Gallium 0.4 on AMD POLARIS10 (DRM 3.2.0 / 4.7.4-gentoo, LLVM 3.9.0)
OpenGL version string:                  OpenGL ES 3.1 Mesa 12.1.0-devel (git-8ce2afe)
OpenGL shading language version string: OpenGL ES GLSL ES 3.10
Driver:                                 Unknown
GPU class:                              Unknown
OpenGL version:                         3.1
GLSL version:                           3.10
Mesa version:                           12.1
X server version:                       1.18.4
Linux kernel version:                   4.7.4
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
No provider of glFenceSync found.  Requires one of:
    Desktop OpenGL 3.2
    GL extension "GL_ARB_sync"
    OpenGL ES 3.0
    GL extension "GL_APPLE_sync"
Application::crashHandler() called with signal 6; recent crashes: 2
KCrash: Application 'kwin_x11' crashing...
KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit

The crash can be reproduced every time.

-- Backtrace:
Application: KWin (kwin_x11), signal: Aborted
Using host libthread_db library "/lib64/libthread_db.so.1".
84	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
[Current thread is 1 (Thread 0x7f647d9b4840 (LWP 7848))]

Thread 11 (Thread 0x7f63c6a7b700 (LWP 7878)):
#0  pthread_cond_timedwait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00007f647b872ca8 in QWaitConditionPrivate::wait_relative (time=30000, this=0x266a270) at thread/qwaitcondition_unix.cpp:126
#2  QWaitConditionPrivate::wait (time=30000, this=0x266a270) at thread/qwaitcondition_unix.cpp:134
#3  QWaitCondition::wait (this=this@entry=0x2296170, mutex=mutex@entry=0x237ee30, time=30000) at thread/qwaitcondition_unix.cpp:208
#4  0x00007f647b86f7a2 in QThreadPoolThread::run (this=0x2296160) at thread/qthreadpool.cpp:127
#5  0x00007f647b87268b in QThreadPrivate::start (arg=0x2296160) at thread/qthread_unix.cpp:341
#6  0x00007f647dd55402 in start_thread (arg=0x7f63c6a7b700) at pthread_create.c:333
#7  0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 10 (Thread 0x7f6447fff700 (LWP 7877)):
#0  pthread_cond_wait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f647ab8f724 in QTWTF::TCMalloc_PageHeap::scavengerThread (this=0x7f647ac736c0 <QTWTF::pageheap_memory>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2359
#2  0x00007f647ab8f769 in QTWTF::TCMalloc_PageHeap::runScavengerThread (context=<optimized out>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1464
#3  0x00007f647dd55402 in start_thread (arg=0x7f6447fff700) at pthread_create.c:333
#4  0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 9 (Thread 0x7f64550ab700 (LWP 7876)):
#0  0x00007f647da94453 in select () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f647ba52d1f in qt_safe_select (nfds=39, fdread=fdread@entry=0x7f644c000a78, fdwrite=fdwrite@entry=0x7f644c000d08, fdexcept=fdexcept@entry=0x7f644c000f98, orig_timeout=orig_timeout@entry=0x0) at kernel/qcore_unix.cpp:75
#2  0x00007f647ba54109 in QEventDispatcherUNIX::select (timeout=0x0, exceptfds=0x7f644c000f98, writefds=0x7f644c000d08, readfds=0x7f644c000a78, nfds=<optimized out>, this=0x7f644c0008c0) at kernel/qeventdispatcher_unix.cpp:320
#3  QEventDispatcherUNIXPrivate::doSelect (this=this@entry=0x7f644c0008e0, flags=..., flags@entry=..., timeout=timeout@entry=0x0) at kernel/qeventdispatcher_unix.cpp:196
#4  0x00007f647ba5460a in QEventDispatcherUNIX::processEvents (this=0x7f644c0008c0, flags=...) at kernel/qeventdispatcher_unix.cpp:607
#5  0x00007f647ba086ca in QEventLoop::exec (this=this@entry=0x7f64550aad60, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#6  0x00007f647b86e2e4 in QThread::exec (this=this@entry=0x240fa10) at thread/qthread.cpp:500
#7  0x00007f647656d705 in QQmlThreadPrivate::run (this=0x240fa10) at qml/ftw/qqmlthread.cpp:141
#8  0x00007f647b87268b in QThreadPrivate::start (arg=0x240fa10) at thread/qthread_unix.cpp:341
#9  0x00007f647dd55402 in start_thread (arg=0x7f64550ab700) at pthread_create.c:333
#10 0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 8 (Thread 0x7f6455ded700 (LWP 7875)):
#0  pthread_cond_timedwait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x00007f647b872ca8 in QWaitConditionPrivate::wait_relative (time=30000, this=0x237f090) at thread/qwaitcondition_unix.cpp:126
#2  QWaitConditionPrivate::wait (time=30000, this=0x237f090) at thread/qwaitcondition_unix.cpp:134
#3  QWaitCondition::wait (this=this@entry=0x2355460, mutex=mutex@entry=0x237ee30, time=30000) at thread/qwaitcondition_unix.cpp:208
#4  0x00007f647b86f7a2 in QThreadPoolThread::run (this=0x2355450) at thread/qthreadpool.cpp:127
#5  0x00007f647b87268b in QThreadPrivate::start (arg=0x2355450) at thread/qthread_unix.cpp:341
#6  0x00007f647dd55402 in start_thread (arg=0x7f6455ded700) at pthread_create.c:333
#7  0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 7 (Thread 0x7f6457855700 (LWP 7863)):
#0  0x00007f647da94453 in select () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f647ba52d1f in qt_safe_select (nfds=30, fdread=fdread@entry=0x7f6450000a78, fdwrite=fdwrite@entry=0x7f6450000d08, fdexcept=fdexcept@entry=0x7f6450000f98, orig_timeout=orig_timeout@entry=0x0) at kernel/qcore_unix.cpp:75
#2  0x00007f647ba54109 in QEventDispatcherUNIX::select (timeout=0x0, exceptfds=0x7f6450000f98, writefds=0x7f6450000d08, readfds=0x7f6450000a78, nfds=<optimized out>, this=0x7f64500008c0) at kernel/qeventdispatcher_unix.cpp:320
#3  QEventDispatcherUNIXPrivate::doSelect (this=this@entry=0x7f64500008e0, flags=..., flags@entry=..., timeout=timeout@entry=0x0) at kernel/qeventdispatcher_unix.cpp:196
#4  0x00007f647ba5460a in QEventDispatcherUNIX::processEvents (this=0x7f64500008c0, flags=...) at kernel/qeventdispatcher_unix.cpp:607
#5  0x00007f647ba086ca in QEventLoop::exec (this=this@entry=0x7f6457854d50, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#6  0x00007f647b86e2e4 in QThread::exec (this=this@entry=0x7f64759c5680 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread.cpp:500
#7  0x00007f6475953565 in QDBusConnectionManager::run (this=0x7f64759c5680 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at qdbusconnection.cpp:189
#8  0x00007f647b87268b in QThreadPrivate::start (arg=0x7f64759c5680 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:341
#9  0x00007f647dd55402 in start_thread (arg=0x7f6457855700) at pthread_create.c:333
#10 0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 6 (Thread 0x7f6458f32700 (LWP 7862)):
#0  pthread_cond_wait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f6466a25ff3 in cnd_wait (mtx=0x2294bb8, cond=0x2294be0) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0x22997c0) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/src/gallium/auxiliary/util/u_queue.c:76
#3  0x00007f6466a25e57 in impl_thrd_routine (p=<optimized out>) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:87
#4  0x00007f647dd55402 in start_thread (arg=0x7f6458f32700) at pthread_create.c:333
#5  0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 5 (Thread 0x7f6459733700 (LWP 7861)):
#0  pthread_cond_wait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f6466a25ff3 in cnd_wait (mtx=0x2294bb8, cond=0x2294be0) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0x229a140) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/src/gallium/auxiliary/util/u_queue.c:76
#3  0x00007f6466a25e57 in impl_thrd_routine (p=<optimized out>) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:87
#4  0x00007f647dd55402 in start_thread (arg=0x7f6459733700) at pthread_create.c:333
#5  0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 4 (Thread 0x7f6459f34700 (LWP 7860)):
#0  pthread_cond_wait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f6466a25ff3 in cnd_wait (mtx=0x2294bb8, cond=0x2294be0) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0x22997c0) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/src/gallium/auxiliary/util/u_queue.c:76
#3  0x00007f6466a25e57 in impl_thrd_routine (p=<optimized out>) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:87
#4  0x00007f647dd55402 in start_thread (arg=0x7f6459f34700) at pthread_create.c:333
#5  0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 3 (Thread 0x7f645a735700 (LWP 7859)):
#0  pthread_cond_wait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f6466a25ff3 in cnd_wait (mtx=0x2294bb8, cond=0x2294be0) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0x229a140) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/src/gallium/auxiliary/util/u_queue.c:76
#3  0x00007f6466a25e57 in impl_thrd_routine (p=<optimized out>) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:87
#4  0x00007f647dd55402 in start_thread (arg=0x7f645a735700) at pthread_create.c:333
#5  0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7f645b13d700 (LWP 7858)):
#0  pthread_cond_wait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f6466a25ff3 in cnd_wait (mtx=0x2293f00, cond=0x2293f28) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:159
#2  util_queue_thread_func (input=input@entry=0x2295ff0) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/src/gallium/auxiliary/util/u_queue.c:76
#3  0x00007f6466a25e57 in impl_thrd_routine (p=<optimized out>) at /usr/src/debug/media-libs/mesa-9999/mesa-9999/include/c11/threads_posix.h:87
#4  0x00007f647dd55402 in start_thread (arg=0x7f645b13d700) at pthread_create.c:333
#5  0x00007f647da9b56d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7f647d9b4840 (LWP 7848)):
[KCrash Handler]
#6  0x00007f647d9e8d38 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#7  0x00007f647d9ea069 in __GI_abort () at abort.c:89
#8  0x00007f6476d069d2 in gl_provider_resolver (name=<optimized out>, providers=0x7f6476d4fb48 <providers>, entrypoints=<optimized out>) at gl_generated_dispatch.c:8771
#9  0x00007f6476d2bbf4 in epoxy_glFenceSync_resolver () at gl_generated_dispatch.c:17010
#10 epoxy_glFenceSync_global_rewrite_ptr (condition=37143, flags=0) at gl_generated_dispatch.c:45997
#11 0x00007f6476fb8cf4 in KWin::GLVertexBuffer::endOfFrame (this=0x265b170) at /usr/src/debug/kde-plasma/kwin-5.7.5/kwin-5.7.5/libkwineffects/kwinglutils.cpp:2269
#12 0x00007f647d66a384 in KWin::SceneOpenGL::paint (this=0x265ec80, damage=..., toplevels=...) at /usr/src/debug/kde-plasma/kwin-5.7.5/kwin-5.7.5/scene_opengl.cpp:748
#13 0x00007f647d64588a in KWin::Compositor::performCompositing (this=this@entry=0x2385ac0) at /usr/src/debug/kde-plasma/kwin-5.7.5/kwin-5.7.5/composite.cpp:720
#14 0x00007f647d645fd6 in KWin::Compositor::startupWithWorkspace (this=0x2385ac0) at /usr/src/debug/kde-plasma/kwin-5.7.5/kwin-5.7.5/composite.cpp:341
#15 0x00007f647d646933 in KWin::Compositor::slotCompositingOptionsInitialized (this=this@entry=0x2385ac0) at /usr/src/debug/kde-plasma/kwin-5.7.5/kwin-5.7.5/composite.cpp:269
#16 0x00007f647d646e62 in KWin::Compositor::setup (this=0x2385ac0) at /usr/src/debug/kde-plasma/kwin-5.7.5/kwin-5.7.5/composite.cpp:180
#17 0x00007f647d64815a in KWin::Compositor::slotReinitialize (this=0x2385ac0) at /usr/src/debug/kde-plasma/kwin-5.7.5/kwin-5.7.5/composite.cpp:486
#18 0x00007f647d7124c5 in KWin::Compositor::qt_metacall (this=0x2385ac0, _c=QMetaObject::InvokeMetaMethod, _id=7, _a=0x7fff2d258030) at /usr/src/debug/kde-plasma/kwin-5.7.5/kwin-5.7.5_build/moc_composite.cpp:332
#19 0x00007f647595e7a6 in QDBusConnectionPrivate::deliverCall (this=<optimized out>, object=<optimized out>, msg=..., metaTypes=..., slotIdx=<optimized out>) at qdbusintegrator.cpp:978
#20 0x00007f647ba31391 in QObject::event (this=0x2385ac0, e=<optimized out>) at kernel/qobject.cpp:1256
#21 0x00007f647c238d0c in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x2385ac0, e=0x7f645000e920) at kernel/qapplication.cpp:3804
#22 0x00007f647c23e12d in QApplication::notify (this=0x7fff2d258610, receiver=0x2385ac0, e=0x7f645000e920) at kernel/qapplication.cpp:3561
#23 0x00007f647ba09809 in QCoreApplication::notifyInternal2 (receiver=0x2385ac0, event=event@entry=0x7f645000e920) at kernel/qcoreapplication.cpp:1015
#24 0x00007f647ba0b7d8 in QCoreApplication::sendEvent (event=0x7f645000e920, receiver=<optimized out>) at kernel/qcoreapplication.h:225
#25 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x2218e00) at kernel/qcoreapplication.cpp:1650
#26 0x00007f647ba544ea in QEventDispatcherUNIX::processEvents (this=0x22efb70, flags=flags@entry=...) at kernel/qeventdispatcher_unix.cpp:579
#27 0x00007f6468a6a925 in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at eventdispatchers/qunixeventdispatcher.cpp:62
#28 0x00007f647ba086ca in QEventLoop::exec (this=this@entry=0x7fff2d258500, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#29 0x00007f647ba0ffa4 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1285
#30 0x00007f647bd313fc in QGuiApplication::exec () at kernel/qguiapplication.cpp:1607
#31 0x00007f647c235df5 in QApplication::exec () at kernel/qapplication.cpp:2979
#32 0x00007f647df77121 in kdemain (argc=3, argv=0x7fff2d258798) at /usr/src/debug/kde-plasma/kwin-5.7.5/kwin-5.7.5/main_x11.cpp:466
#33 0x00007f647d9d66f0 in __libc_start_main (main=0x400780 <main(int, char**)>, argc=3, argv=0x7fff2d258798, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff2d258788) at ../csu/libc-start.c:289
#34 0x00000000004007b9 in _start ()

Possible duplicates by query: bug 340254.

Reported using DrKonqi
Comment 1 Martin Flöser 2016-10-04 07:48:05 UTC
This is a driver bug. It reports OpenGL ES 3.1, but doesn't provide all functionality of it:

From the debug output
No provider of glFenceSync found. Requires one of:
 Desktop OpenGL 3.2
 GL extension "GL_ARB_sync"
 OpenGL ES 3.0
 GL extension "GL_APPLE_sync"
Comment 2 Andrei Slavoiu 2016-10-07 00:33:49 UTC
That is not true, glFenceSync is provided by the driver and a simple test program based on the gles2 test of epoxy is able to call it without issue on the same system. The problem is with the way kwin uses epoxy. The only logical explanation is that epoxy believes the context is a Desktop OpenGL one and so it compares the version reported by the driver with 3.2 instead of 3.0 as it should. Btw, this issue is most likely not reproduce-able with an Intel card as Intel exposes OpenGL ES 3.2
Comment 3 Andrei Slavoiu 2016-10-07 00:34:37 UTC
Created attachment 101459 [details]
epoxy_test.c
Comment 4 Martin Flöser 2016-10-07 05:42:48 UTC
> That is not true, glFenceSync is provided by the driver and a simple test program based on the gles2 test of epoxy is able to call it without issue on the same system.

Your test program is not creating a pure OpenGL ES context - sorry to say so. You create an OpenGL context through GLX and then the compatibility extension. But KWin is doing proper GLES using EGL and creating an OpenGL ES context directly. It's not using GLX! It is possible that the driver reports different things depending on how the context is created. Especially as the way you created it loads libgl.so instead of libgles.so.

I'm sorry, but the code you attached doesn't show that there is something wrong in KWin. Heck our code works on hardware which doesn't have OpenGL at all - e.g. the Nexus 5 or Odroid. Of course it uses proper OpenGL ES and epoxy knows it's using OpenGL ES.
Comment 5 Andrei Slavoiu 2016-10-07 23:06:06 UTC
I finally figured out what is going on here, it looks like epoxy is unable to distinguish between GLES and regular GL contexts created using EGL on the mesa implementation (which returns EGL_OPENGL_API when queried about the type of the current context even when it actually is a GLES one. However weird that may sound it's perfectly ok to do that per spec) because of a workaround they did for the non standards compliant PowerVR driver. The epoxy bug url: https://github.com/anholt/libepoxy/issues/25

So you may wonder why I reopened this bug again if all you can do about it is pressure epoxy to fix their own bug? Because there actually is an issue in kwin as well. When using Desktop OpenGL kwin should either request an OpenGL 3.2 context or check for the GL_ARB_sync extension in order to use glFenceSync (according to epoxy code). However, kwin will create a OpenGL 3.1 context and never check for the presence of the GL_ARB_sync extension.

Now, to anyone else hitting this bug, an easy workaround for it is to remove the code under #if PLATFORM_HAS_EGL from the implementation of epoxy_is_desktop_gl, that's it.
Comment 6 Martin Flöser 2016-10-08 13:19:12 UTC
*** Bug 370264 has been marked as a duplicate of this bug. ***
Comment 7 Martin Flöser 2016-10-08 13:21:33 UTC
Thanks for the good investigation.

> When using Desktop OpenGL kwin should either request an OpenGL 3.2 context or check for the GL_ARB_sync extension in order to use glFenceSync

Normally one does not need to explicitly request OpenGL 3.2 - we get 3.2 if it's supported. But looks like we should add runtime checks to the syncing code. I'll read up on it on Monday and try to come up with a change. I understand that you could test patches, right?
Comment 8 Yury Zhuravlev 2016-10-08 14:20:12 UTC
Thanks Andrei, with https://github.com/yaronct/libepoxy everything works well!
Comment 9 Martin Flöser 2016-10-08 17:48:14 UTC
I just had a look at the implementation and alas our code does the correct checks - see libkwineffects/kwinglutils.cpp method GLVertexBuffer::initStatic (around like 2290)

In  short it's:

    if (GLPlatform::instance()->isGLES()) {
        GLVertexBufferPrivate::haveSyncFences = hasGLVersion(3, 0);
    } else {
        GLVertexBufferPrivate::haveSyncFences = hasGLVersion(3, 2) || hasGLExtension("GL_ARB_sync");
    }
    if (GLVertexBufferPrivate::haveBufferStorage && GLVertexBufferPrivate::haveSyncFences) {
        if (qgetenv("KWIN_PERSISTENT_VBO") != QByteArrayLiteral("0")) {
            GLVertexBufferPrivate::streamingBuffer->d->persistent = true;
        }
    }

Only if the d->persistent is true the glFenceSync is called. Thus the checks look correct to me. We check for either GLES 3.0, or GL 3.2 or GL_ARB_sync. Our code cannot do more. If the upstream project is broken in that regard, it's unfortunate. I guess we need to get distros to switch to the fork.

Ah I'm not happy with that development. That was kind of what I was afraid of to happen when we switch to epoxy.
Comment 10 Yury Zhuravlev 2016-10-08 18:34:24 UTC
> I guess we need to get distros to switch to the fork.

I started - https://bugs.gentoo.org/show_bug.cgi?id=596548