I have Intel Haswell based laptop with drm-fbsd12.0-kmod on 12.1-STABLE installed. When I run Firefox, Xorg starts to consume 10% of CPU and system becomes unresponsible to user input. Even if I close Firefox, system still in this state until I reload the graphical session. With old i915 and drm2 that still in the tree for 12.1-STABLE everything works fine.
Have you recompiled the module after installing FreeBSD 12.1?
(In reply to Niclas Zeising from comment #1) Hi Niclas, The system and the module are recompiled from source. Thanks for reply!
Are you using an Xorg.conf on this system? Also, would you be able to post your Xorg.0.log?
Created attachment 208825 [details] Xorg config for video
Created attachment 208826 [details] Xorg log file
(In reply to pete from comment #3) Uploaded config and log. But I remember that I already saw a similar problem on another desktop system, also with Haswell CPU. Thanks!
(In reply to Oleh Hushchenkov from comment #6) Thanks for posting those files. Is it possible to reproduce this issue with no xorg.conf in place. This should cause Xorg to auto-configure and use the modesetting Xorg driver. Also, do you notice anything interesting in /var/log/messages or in your dmesg buffer when the system gets into this state?
(In reply to pete from comment #7) I found that a cause of the problem is Option "TearFree" "true" in config file. Without this option there is no issue. With modesetting driver there is also no issue. But... without this option or with modesetting driver I have tearing... There is no way to use it without tearfree option.
(In reply to pete from comment #7) /var/log/messages has nothing about the issue.
Does disabling framebuffer compression help? Add either compat.linuxkpi.enable_fbc=0 or compat.linuxkpi.i915_enable_fbc=0 to /boot/loader.conf then reboot (or reload i915kms). Does replacing TearFree with compton-yshui (aka picom) with --backend glx and --vsync help? Add --use-damage to improve performance.
(In reply to Oleh Hushchenkov from comment #8) This reads as being very similar to my experience with Intel(R) HD Graphics 530 (Skylake GT2). If this is really an Xorg problem and not a DRM problem, might it be resolved by bug #236003?
Another way to trigger this behavior is running sxiv -abrf -s d $path_to_dir_with_1000_image_files and switch to thumbnail mode. It looks like a resource leak.
(In reply to Jan Beich from comment #10) Looks lite framebuffer compression is disabled by default. compat.linuxkpi.enable_fbc does not exist. compat.linuxkpi.i915_enable_fbc already has 0. Using compton-yshui on this machine leading to performance loss, latency increase and somehow broke video playback with mpv. Enable --use-damage has no impact to performance. But I successfully use compton-yshui on workstation where discrete GPU has enough power to make effect of compton-yshui not so noticeable. Thanks for suggestions!
(In reply to Theron Tarigo from comment #11) I don't think that this is Xorg problem because it works pretty well on old DRM from base. It looks like a regression. But with old DRM performance is low and I can't use VAAPI to decode video. I will look on bug #236003. Thanks!
It seems like patch from bug #236003 (xf86-video-intel: update to 2019-07-10 snapshot and refactor) solved this! So I will close this as solved. Thanks Jan for the patch and Theron for pointing me on that.