When using DRI3+Present with PRIME render offload, sometimes there is a mismatch between the stride of the to-be-presented Pixmap and the frontbuffer. The current code would reject a pageflip present in this case if atomic modesetting is not enabled, ie. always, as atomic modesetting is disabled by default due to brokeness in the current modesetting-ddx. Fullscreen presents without page flipping however trigger the copy path as fallback, which causes not only unreliable presentation timing and degraded performance, but also massive tearing artifacts due to rendering to the framebuffer without any hardware sync to vblank. Tearing is extra awful on modesetting-ddx because glamor afaics seems to use drawing of a textured triangle strip for the copy implementation, not a dedicated blitter engine. The rasterization pattern creates extra awful tearing artifacts. We can do better: According to a tip from Michel Daenzer (thanks!), at least atomic modesetting capable kms drivers should be able to reliably change scanout stride during a pageflip, even if atomic modesetting is not actually enabled for the modesetting client. This commit adds detection logic to find out if the underlying kms driver is atomic_modeset_capable, and if so, it no longer rejects page flip presents on mismatched stride between new Pixmap and frontbuffer. We (ab)use a call to drmSetClientCap(ms->fd, DRM_CLIENT_CAP_ATOMIC, 0); for this purpose. The call itself has no practical effect, as it requests disabling atomic mode, although atomic mode is disabled by default. However, the return value of drmSetClientCap() tells us if the underlying kms driver is atomic modesetting capable: An atomic driver will return 0 for success. A legacy non-atomic driver will return a non-zero error code, either -EINVAL for early atomic Linux versions 4.0 - 4.19 (or for non-atomic Linux 3.x and earlier), or -EOPNOTSUPP for Linux 4.20 and later. Testing on a MacBookPro 2017 with Intel Kabylake display server gpu + AMD Polaris11 as prime renderoffload gpu, X-Server master + Mesa 21.0.3 show improvement from unbearable tearing to perfect, despite a stride mismatch between display gpu and Pixmap of 11776 Bytes vs. 11520 Bytes. That this is correct behaviour was also confirmed by comparing the behaviour and .check_flip implementation of the patched modesetting-ddx against the current intel-ddx SNA Present implementation. Please consider merging this patch before the server-1.21 branch point. This patch could also be cherry-picked into the server 1.20 branch to fix the same limitation. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> |
||
---|---|---|
.gitlab-ci | ||
Xext | ||
Xi | ||
composite | ||
config | ||
damageext | ||
dbe | ||
dix | ||
doc | ||
dri3 | ||
exa | ||
fb | ||
glamor | ||
glx | ||
hw | ||
include | ||
m4 | ||
man | ||
mi | ||
miext | ||
os | ||
present | ||
pseudoramiX | ||
randr | ||
record | ||
render | ||
test | ||
xfixes | ||
xkb | ||
.appveyor.yml | ||
.dir-locals.el | ||
.gitignore | ||
.gitlab-ci.yml | ||
.travis.yml | ||
COPYING | ||
Makefile.am | ||
README.md | ||
autogen.sh | ||
configure.ac | ||
devbook.am | ||
docbook.am | ||
manpages.am | ||
meson.build | ||
meson_options.txt | ||
xorg-server.m4 | ||
xorg-server.pc.in | ||
xserver.ent.in |
X Server
The X server accepts requests from client applications to create windows, which are (normally rectangular) "virtual screens" that the client program can draw into.
Windows are then composed on the actual screen by the X server (or by a separate composite manager) as directed by the window manager, which usually communicates with the user via graphical controls such as buttons and draggable titlebars and borders.
For a comprehensive overview of X Server and X Window System, consult the following article: https://en.wikipedia.org/wiki/X_server
All questions regarding this software should be directed at the Xorg mailing list:
https://lists.freedesktop.org/mailman/listinfo/xorg
The primary development code repository can be found at:
https://gitlab.freedesktop.org/xorg/xserver
For patch submission instructions, see:
https://www.x.org/wiki/Development/Documentation/SubmittingPatches
As with other projects hosted on freedesktop.org, X.Org follows its Code of Conduct, based on the Contributor Covenant. Please conduct yourself in a respectful and civilized manner when using the above mailing lists, bug trackers, etc: