Bug 99547 - OpenGL window refreshes extremely slow on UDL
Summary: OpenGL window refreshes extremely slow on UDL
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/modesetting (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-26 11:49 UTC by Tad
Modified: 2018-12-13 18:09 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Tad 2017-01-26 11:49:42 UTC
When I move glxgears (or any other app that uses opengl) to the screen on monitor attached to UDL device, it starts refreshing itself in about one second periods, so monitors attached to UDL are not usable.

Here's backtrace from glxgears during hang:
#0  0x00007f80ac3330a0 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f80aa742c62 in poll (__timeout=-1, __nfds=1, __fds=0x7ffc0e905c80) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0x558195104410, cond=cond@entry=0x558195112bf8, vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:459
#3  0x00007f80aa7449a9 in xcb_wait_for_special_event (c=0x558195104410, se=0x558195112bd0) at ../../src/xcb_in.c:789
#4  0x00007f80acc914b7 in dri3_find_back (draw=draw@entry=0x5581951129d8) at loader_dri3_helper.c:380
#5  0x00007f80acc92280 in dri3_get_buffer (driDrawable=0x7ffc0e905e80, draw=0x5581951129d8, buffer_type=loader_dri3_buffer_back, format=4098) at loader_dri3_helper.c:1196
#6  loader_dri3_get_buffers (driDrawable=driDrawable@entry=0x558195112ad0, format=4098, stamp=stamp@entry=0x558195112b00, loaderPrivate=loaderPrivate@entry=0x5581951129d8, buffer_mask=<optimized out>, buffer_mask@entry=1, buffers=buffers@entry=0x7ffc0e905e80)
    at loader_dri3_helper.c:1373
#7  0x00007f80a93b8918 in intel_update_image_buffers (drawable=0x558195112ad0, brw=0x7f80ad082038) at brw_context.c:1682
#8  intel_update_renderbuffers (context=context@entry=0x55819524d610, drawable=drawable@entry=0x558195112ad0) at brw_context.c:1397
#9  0x00007f80a93b8c71 in intel_prepare_render (brw=brw@entry=0x7f80ad082038) at brw_context.c:1418
#10 0x00007f80a9396c70 in brw_clear (ctx=0x7f80ad082038, mask=18) at brw_clear.c:232
#11 0x00005581932c94ae in draw () at glxgears.c:254
#12 0x00005581932c8c28 in draw_gears () at glxgears.c:316
#13 draw_frame (win=52428802, dpy=0x558195103010) at glxgears.c:341
#14 event_loop (win=52428802, dpy=0x558195103010) at glxgears.c:703
#15 main (argc=<optimized out>, argv=<optimized out>) at glxgears.c:798

It looks like it's waiting till xserver sends back idle event. And its going to do that after it receives vblank associated to that particular opengl window. But vblank is scheduled with timer (which executes in about a second) because xserver cannot find proper crtc. XServer uses ms_covering_crtc function to match window dimensions to those available in scrn's config. Looks like proper crtc not exists on the list:

#0  ms_covering_crtc (scrn=0x558aea71f110, box=box@entry=0x7ffe4c160de0, desired=desired@entry=0x0, crtc_box_ret=crtc_box_ret@entry=0x7ffe4c160df0) at ../../../../../hw/xfree86/drivers/modesetting/vblank.c:103
#1  0x00007f507ba5c976 in ms_dri2_crtc_covering_drawable (pDraw=0x558aeba85780) at ../../../../../hw/xfree86/drivers/modesetting/vblank.c:151
#2  0x00007f507ba5c1f9 in ms_present_get_crtc (window=<optimized out>) at ../../../../../hw/xfree86/drivers/modesetting/present.c:62
#3  0x0000558ae842f0d1 in present_pixmap (window=0x558aeba85780, pixmap=0x558aeb898330, serial=3644, valid=0x0, update=0x0, x_off=<optimized out>, y_off=0, target_crtc=<optimized out>, wait_fence=0x0, idle_fence=0x558aec0a8af0, options=0, window_msc=2987391, divisor=0, remainder=0, notifies=0x0, num_notifies=0) at ../../present/present.c:812
#4  0x0000558ae8430775 in proc_present_pixmap (client=0x558aec1afd40) at ../../present/present_request.c:138
#5  0x0000558ae83473bf in Dispatch () at ../../dix/dispatch.c:430
#6  0x0000558ae834b413 in dix_main (argc=11, argv=0x7ffe4c161168, envp=<optimized out>) at ../../dix/main.c:300
#7  0x00007f507f93c3f1 in __libc_start_main (main=0x558ae8335300 <main>, argc=11, argv=0x7ffe4c161168, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe4c161158) at ../csu/libc-start.c:291
#8  0x0000558ae833533a in _start ()

XServer version:
X.Org X Server 1.18.4
Release Date: 2016-07-19
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-45-generic x86_64 Ubuntu
Current Operating System: Linux 4.8.0-34-generic #36-Ubuntu SMP Wed Dec 21 17:24:18 UTC 2016 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.8.0-34-generic root=UUID=046d556a-159d-4ea2-a644-664d550b3395 ro quiet splash vt.handoff=7
xorg-server 2:1.18.4-1ubuntu6.1 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.33.6
Comment 1 Max Zhao 2017-02-17 19:52:34 UTC
Can report that the same behavior is present on Linux 4.9.8 with Xorg 1.19.1.
Comment 2 Jason Pickering 2017-05-29 12:42:00 UTC
Same thing is happening to me on an Dell XPS13 with Ubuntu. Version: 1:7.7+13ubuntu3
Comment 3 GitLab Migration User 2018-12-13 18:09:08 UTC
-- 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/xorg/xserver/issues/22.


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.