Modesetting tearing

[moosotc@gmail.com]

moosotc@gmail.com writes:

> moosotc@gmail.com writes:
>

[..snip..]

Demonstration:

$ curl -O https://boblycat.org/~malc/teartest.c
$ gcc -o teartest -lGL -lSDL2 teartest.c
$ ./teartest
# Press 'p' - no tearing
$ screenkey --no-detach --persist # in a spare terminal [1]
# tearing
$ pkill screenkey
# no tearing
$ xrandr -x
# tearing
$ xrandr -x
# no tearing
$ compton --backend glx # in a spare terminal [2]
$ screenkey --no-detach --persist # in a spare terminal
# no tearing
$ pkill screenkey
$ xrandr -x
# tearing (NB compton is still running)
$ xrandr -x
# no tearing

All of the above was done while i3 [3] was managing windows and all of
them were floating [4].

Doesn't tear by default in mutter, tears when the screen was
reflected/rotated.

Bottom-line things tear with modesetting irrespective of compositors
tried. (There was also a test with xfwm4's compositor but it's
behavior was rather strange so not included here, other than a short
remark that it could be made to tear too, ditto enlightenment).

With /etc/X11/xorg.conf.d/20-intel.conf containing following tearing
is gone.

Section "Device"
    Identifier "intel"
    Driver     "intel"
    Option     "TearFree" "true"
    Option     "DRI" "2"
EndSection

But with intel driver another issue was seen more than once:

Starting program: /home/malc/bin/llpp TOPLAS_submission.pdf
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffefd82700 (LWP 1671)]
intel_do_flush_locked failed: Cannot allocate memory

Thread 1 "llpp" hit Breakpoint 2, 0x00007ffff6683570 in exit () from /usr/lib/li
bc.so.6
(gdb) bt
#0  0x00007ffff6683570 in exit () from /usr/lib/libc.so.6
#1  0x00007ffff2f001fe in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#2  0x00007ffff512eb78 in ?? () from /usr/lib/libGLX_mesa.so.0
#3  0x00005555555b10c0 in ml_swapb (unit_v=<optimized out>) at link.c:3993
#4  0x00005555557ef881 in caml_interprete ()
#5  0x00005555557f1ce6 in caml_main ()
#6  0x000055555559faec in main ()
(gdb) quit

All of this while linux was configured not to overcommit:
  vm.nr_overcommit_hugepages = 0
  vm.overcommit_kbytes = 0
  vm.overcommit_memory = 2
  vm.overcommit_ratio = 90

Also there was no swap, how things would behave if swap was enabled
and/or overcommit allowed is an open question.

Same thing (i.e. 965 calling exit on an unsuspecting application that
merely tried to swap buffers) happened few times when mpv was playing
a video using opengl video output, however DRI3 was disabled via an
environment variable and TearFree was off when that happened.

Further reading:
https://bugzilla.freedesktop.org/show_bug.cgi?id=101827
https://lists.freedesktop.org/archives/intel-gfx/2017-July/133103.html
https://lists.freedesktop.org/archives/intel-gfx/2017-July/133244.html

It's probably worth pointing out that teartest tears here even when
invoked inside weston (using Xwayland though) It might take some time
(few seconds) for it to start tearing but it does happen.

[1] https://github.com/wavexx/screenkey
[2] https://github.com/chjj/compton/
[3] https://i3wm.org/
[4] https://github.com/moosotc/snippets/blob/master/.config/i3/config

P.S. Will try working with 20-intel.conf as above for a few days and
     see if it (i.e. "intel_do_flush_locked failed: Cannot allocate
     memory") will happen agin. Sadly:

             Testing shows the presence, not the absence of bugs.
                     Edsger Wybe Dijkstra

-- 
mailto:moosotc@gmail.com

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx