| Summary: | glXSwapBuffers() can cause BadMatch or lock X when performed repeatedly | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Seán de Búrca <leftmostcat> |
| Component: | GLX | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | CC: | eero.t.tamminen |
| Version: | 10.4 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Test program demonstrating crash/lock | ||
What about the X server and X intel driver versions? Are you using DRI2 or DRI3? If latter, can you reproduce the issue also with DRI2? I believe I'm using DRI2. My Xorg logs contain the following: (II) GLX: Initialized DRI2 GL provider for screen 0 If this may be incorrect, please let me know. I am using xorg-server 1.16.2.901 and X Intel driver 2.99.916. On SKL with Ubuntu 16.04, using latest Mesa from Git everything seems to work fine, same with older Mesa 11.2 coming with Ubuntu. No crashes / locks either with Intel DDX or modesetting, with DRI3 or DRI2.
I would think that the issue is either fixed in Mesa, or culprit is something else than Mesa. Can you try newer Mesa, and if that doesn't help, newer Intel DDX version?
Btw. your test program shows interesting difference between DRI3 & DRI2.
I increased the test loop count a bit. With Intel XX / DRI2, test goes through 10 000 rounds "instantly".
With DRI3, it takes 5-10x longer, and perf says following of the Xorg 100% CPU usage:
-------------------------------------
23.83% Xorg Xorg [.] SyncAddTriggerToSyncObject
18.20% Xorg intel_drv.so [.] 0x000000000010a5e5
16.83% Xorg Xorg [.] TimerSet
16.49% Xorg Xorg [.] present_pixmap
14.41% Xorg Xorg [.] present_event_notify
7.96% Xorg Xorg [.] SyncDeleteTriggerFromSyncObject
...
-------------------------------------
With modesetting instead of Intel DDX:
- test takes even longer and seems to be limited to 60 FPS
- with DRI2, CPU usage is ~1% (LIBGL_DRI3_DISABLE=1 Mesa option)
- with DRI3, CPU usage is 100%
-------------------------------------
Overview:
98.99% Xorg
80.49% [kernel.kallsyms]
6.66% [unknown] (I think this is on kernel side also)
5.12% [vdso]
3.99% modesetting_drv.so
1.68% libc-2.23.so
1.64% libdrm.so.2.4.0
Details:
16.55% Xorg [kernel.kallsyms] [k] copy_user_enhanced_fast_string
9.27% Xorg [kernel.kallsyms] [k] do_sys_poll
8.13% Xorg [kernel.kallsyms] [.] entry_SYSCALL_64_fastpath
5.43% Xorg [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
4.51% Xorg [kernel.kallsyms] [k] entry_SYSCALL_64_after_swapgs
4.44% Xorg [kernel.kallsyms] [k] _raw_spin_lock_irqsave
4.20% Xorg [kernel.kallsyms] [k] kfree
3.79% Xorg [kernel.kallsyms] [k] drm_ioctl
3.48% Xorg [kernel.kallsyms] [k] drm_wait_vblank
3.44% Xorg [kernel.kallsyms] [k] kmem_cache_alloc_trace
-------------------------------------
In general, with DRI3, first (few thousand) swaps go faster than the later ones.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/97. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 112152 [details] Test program demonstrating crash/lock When running a simple program to test window and GL context creation, I experience program crashes or X lockups when the main loop calls glXSwapBuffers() too rapidly. When the swap interval is not set, this appears to always cause X to lock, with only the mouse responding. (n.b. When attempting to drag windows, the cursor changes appropriately but the windows do not respond.) If glXSwapIntervalMESA(1) is called, this occasionally merely results in a program crash after some number of loops. In both cases, the following error appears in the output and the program stops execution: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 147 () Minor opcode of failed request: 1 Serial number of failed request: 163 Current serial number in output stream: 1034 After the end of execution, if X is locked, it remains locked until restarted. Putting a one second delay into the main loop prevents the crash and programs using GLX while rendering real results have not yet elicited any crashes, suggesting this is a race condition somewhere. The test program I am using to reproduce this is attached. I am using mesa 10.4.1 with the i965 drivers on an Intel HD 3000 with kernel 3.17.8. All packages are from the Fedora 21 repositories.