Modesetting tearing without compositor

Modesetting tearing without compositor

[moosotc]

Hello,

By default tearing is evident when running full-screen OpenGL
applications such as [1] or playing one of the numerous tearing test
videos from youtube in mpv (with mpv's xv, opengl or vaapi video output
drivers, I guess glamor implements xv via OpenGL so no surprise there).

By accident I've discovered that enabling frame buffer compression
(i915's enable_fbc parameter) before X is started stops tearing.

There are ways to get tearing again though, for instance: if full-screen
OpenGL window is present, being constantly redrawn and window in an
override redirect state[2] is mapped atop of it. Tear free operation can
be restored in my setup by playing with xrandr ("xrandr -x; xrandr -x"
for instance) or switching to a spare VT and then back to X.

The full-screen+override-redirect way of "enabling tearing" works for
normal and inverted orientations (xrandr -o [normal|inverted]) but not
reflected or left|right rotated.

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Grap
hics Controller (rev 09)

$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Haswell Mobile  (0xa26)
    Version: 17.1.4
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.4
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 17.1.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.1.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

$ modinfo i915 | egrep -v '^(alias|parm)'
filename:       /lib/modules/4.11.9-1-ARCH/kernel/drivers/gpu/drm/i915/i915.ko.g
z
license:        GPL and additional rights
description:    Intel Graphics
author:         Intel Corporation
author:         Tungsten Graphics, Inc.
firmware:       i915/bxt_dmc_ver1_07.bin
firmware:       i915/skl_dmc_ver1_26.bin
firmware:       i915/kbl_dmc_ver1_01.bin
firmware:       i915/kbl_guc_ver9_14.bin
firmware:       i915/bxt_guc_ver8_7.bin
firmware:       i915/skl_guc_ver6_1.bin
firmware:       i915/kbl_huc_ver02_00_1810.bin
firmware:       i915/bxt_huc_ver01_07_1398.bin
firmware:       i915/skl_huc_ver01_07_1398.bin
depends:        drm_kms_helper,drm,intel-gtt,video,button,i2c-algo-bit
intree:         Y
vermagic:       4.11.9-1-ARCH SMP preempt mod_unload modversions

[1] https://boblycat.org/~malc/sdl2.c
[2] i3bar or some rofi[3] window for instance
    Probably worth noting that having rofi pop up while i3bar is
    mapped is not enough, i3bar has to be unmapped first
[3] https://github.com/DaveDavenport/rofi

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

Re: Modesetting tearing without compositor

[moosotc]

moosotc@gmail.com writes:

> Hello,
>
> By default tearing is evident when running full-screen OpenGL
> applications such as [1] or playing one of the numerous tearing test
> videos from youtube in mpv (with mpv's xv, opengl or vaapi video output
> drivers, I guess glamor implements xv via OpenGL so no surprise there).
>
> By accident I've discovered that enabling frame buffer compression
> (i915's enable_fbc parameter) before X is started stops tearing.
>
> There are ways to get tearing again though, for instance: if full-screen
> OpenGL window is present, being constantly redrawn and window in an
> override redirect state[2] is mapped atop of it. Tear free operation can
> be restored in my setup by playing with xrandr ("xrandr -x; xrandr -x"
> for instance) or switching to a spare VT and then back to X.
>
> The full-screen+override-redirect way of "enabling tearing" works for
> normal and inverted orientations (xrandr -o [normal|inverted]) but not
> reflected or left|right rotated.
>

FWIW thea above method of "enabling tearing" does not work if
LIBGL_DRI3_DISABLE was set prior to running offending applications (mpv
or sdl2.c) IOW tearing is defeated.

Leaves big fat "wtf?" question open though.

Several questions are open in fact:

Why tearing avoidance via enable_fbc works and what other effects (other
than tainting kernel) does it have?

Why override-redirect windows cause tearing when DRI3 is used?

Why having the screen reflected, left right rotated defeats tearing even
with DRI3?

Why does "xrandr -y; xrandr -y" after tearing begins brings things back
to normal?

[..snip..]

Any insights it would be most appreciated given that using module
parameters that taint kernel and setting environment variables that
"degrade" (at least in numerical value) supported feature set feel.
rather dirty and unscientific as it were.

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

Modesetting tearing

[moosotc]

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

Re: Modesetting tearing

[moosotc]

moosotc@gmail.com writes:

> moosotc@gmail.com writes:
>
[..snip..]

>
> 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

And it just happened again in mpv, so basically the choices are:

a) Tearing
b) OpenGL applications that suddenly die on you

-- 
mailto:moosotc@gmail.com

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