Created attachment 202331 [details] v1 (has commit message) Tested on Intel HD530 (aka Skylake GT2) + drm-current-kmod (Linux 4.20) + i965/anv (DRI3) + intel (SNA, DRI3) via mpv (EGL + VAAPI, Vulkan), ppsspp (Vulkan), rpcs3 (Vulkan, OpenGL 4.3+), firefox (WebRender). No UXA changes since previous update, so testing on old iGPUs isn't necessary. Build logs: - 11.2 amd64: https://ptpb.pw/jGsv - 11.2 i386: https://ptpb.pw/RT-l - 12.0 amd64: https://ptpb.pw/f3zv - 12.0 i386: https://ptpb.pw/0gRC - 13.0 amd64: https://ptpb.pw/BhBf) - 13.0 i386: https://ptpb.pw/7E3a - UDEV=on: https://ptpb.pw/FQq0
Created attachment 202533 [details] v2 (has commit message)
Am I the only user left?
(In reply to Jan Beich from comment #2) Almost certainly not, but you said that testing in old iGPUs is not needed and, since I have switched to the modesetting driver, I did not try out the code.
I tested this and it seems to work fine.
It works fine here on Kabylake (gen9) / Thinkpad X1 Carbon 6th, too! SNA render acceleration (xfwm w/ compositing), Xv (mplayer), VAAPI, DRI (Firefox), all performant and tear-free. Even though suspend still doesn't work yet, I believe this definitely is an improvement. And, modesetting is not an option for me because I can't afford so-called "tearing" effect, albeit suspend works.
What's holding this? It was tested by real users (excluding me). Long delays every time are very discouraging. Proposing for 2019Q3 as SNA fix (included) for drm-kmod >= 4.11 is too important.
Created attachment 205509 [details] v3 (has commit message) Oops, I had an update but forgot to upload: 2 more upstream SNA fixes.
Comment on attachment 205509 [details] v3 (has commit message) Nevermind. There's no difference between v2 and v3.
Works well on my Thinkpad T470p with Kaby Lake. Not tested yet with external display attached.
Created attachment 206005 [details] v3 (has commit message) More upstream SNA fixes.
Working Fine Here Thanks
Created attachment 206160 [details] v4 (has commit message) More upstream SNA fixes.
Created attachment 207727 [details] v4 (has commit message) Rebase after ports r509895
Created attachment 207959 [details] v5 (has commit message) Upstream warning fixes.
Created attachment 208705 [details] v6 Upstream SNA bugfix
Neglect here suggests "playing solo" from bug 235050 comment 1 was really about self-reflection by the team. Sadly, applying "3 months or 3 timeouts" rule would cause more drama. And creating a new port has poor justification: no breaking changes, downstream-only improvements, cleanup. I really need a new GPU to forget about this port. ;\
v6 works perfectly here, including suspend/resume! I'm looking forward to your work being merged into the stock ports, really! * ThinkPad X1 Carbon gen. 6 (UHD Graphics 620, aka Kabylake gen9) * FreeBSD current r354159 (custom kernel based on MINIMAL + GENERIC-NODEBUG) * drm-current-kmod-4.16.g20191023 * gpu-firmware-kmod-g20191015 * xorg.conf: - AccelMethod sna - TearFree true - TripleBuffer false (I haven't utilize TripleBuffer because TearFree alone is sufficient for my eyes to eliminate noticeable tearing completely) * loader.conf: - compat.linuxkpi.enable_fbc="-1" - compat.linuxkpi.enable_psr="1" - compat.linuxkpi.enable_dc="2" Sorry for being quiet, but I had been busy until recently.
(In reply to Jan Beich from comment #0) Hi, I should have been paying attention to this bug by now, since I have Intel(R) HD Graphics 530 (Skylake GT2). With what has been available in ports, everything since DRM 4.9 kmod (drm-fbsd11.2-kmod-4.9g20181023) has been unusable: With "intel" driver and SNA+TearFree, after a few minutes of Xorg running, or even after launching Firefox, performance becomes terrible, where it feels as though in each 1/60th of a second, there is only a one in three chance of a frame getting pushed to the display). "modesetting" has never worked for me with any drm-kmod without tearing, so I do not use it. Here I thought I was the only user of Intel HD530 and the only one stuck on DRM 4.9. Jan, has this been your experience with "intel" driver? Is this one thing that the update fixes? As long as DRM 4.9 continues to build and run on FreeBSD 12.x I haven't been able to justify putting enormous time into debugging the newer graphics stack, but it sounds like this update may be the fix; I can't tell. (If you'd rather I just try it than ask questions then that is an option for me but it may delay my willingness to test it indefinitely).
(In reply to Theron Tarigo from comment #18) > Hi, I should have been paying attention to this bug by now, since I have > Intel(R) HD Graphics 530 (Skylake GT2). With what has been available in ports, > everything since DRM 4.9 kmod (drm-fbsd11.2-kmod-4.9g20181023) has been > unusable: With "intel" driver and SNA+TearFree, after a few minutes of Xorg > running, or even after launching Firefox, performance becomes terrible, where > it feels as though in each 1/60th of a second, there is only a one in three > chance of a frame getting pushed to the display). I'm on -CURRENT and don't use TearFree due to poor/jerky performance. A few month ago I've seen severe redraw skips on TearFree but don't remember what have fixed those: either upgrading drm-current-kmod to drm-devel-kmod or disabling framebuffer compression. If you see "(EE) intel(0): Failed to submit rendering commands (Bad address), disabling acceleration." in Xorg.log on DRM > 4.9 then this update should help. The full list of changes is documented in the commit message (read the diff).
Created attachment 208834 [details] v6.1 - Fix missing git hash in buildstring (used in Xorg.log) after ports r509895 - Rebase after ports rr516607
Tested on Haswell IGPU. Fixes bug #241685. It have to be committed ASAP. Thanks Jan!
fetch -qo /tmp/intel-ddx-SNA-Fix.diff 'https://bugs.freebsd.org/bugzilla/attachment.cgi?id=208834' patch -Efsp1 -i /tmp/intel-ddx-SNA-Fix.diff -d /usr/ports cd /usr/ports/x11-drivers/xf86-video-intel ; make deinstall reinstall clean
There is a black screen with mouse cursor at center on my Thinkpad T470p with SNA enabled. With UXA all works fine, but sddm is starting about one minute.
Created attachment 209362 [details] v7 Upstream SNA bugfixes.
(In reply to Alexandr Krivulya from comment #23) Can you try v7? If it doesn't help track down which version introduced the regression (may require downgrading the entire ports tree to avoid patch conflicts). After that it should be easy to bisect e.g., 1. Run "git clone https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/" 2. Run "git bisect" using upstream commits from DISTVERSIONSUFFIX (strip "-g") or GL_COMMIT for the first bad and the last good version of the patch 3. Adjust DISTVERSION + DISTVERSIONSUFFIX in the port 4. Run "make makesum" to regen distinfo 5. Run "make clean all deinstall install" to start runtime testing 6. Run "git bisect bad" if still you can reproduce or "git bisect good" if you cannot 7. Repeat 3-6 steps until "git bisect" points to a single commit 8. Append the hash of the first bad to https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/commit/ to get an URL of the commit Once you find what caused upstream regression it should be easier to understand why (unless kernel- or chip-specific), hack to make it work again or simply revert the change.
Whether comment 23 tells about regression since comment 9 is still unclear as comment 9 didn't specify which AccelMethod was tested.
With v7 and UXA all works fine. With SNA enabled I have the same situation - black screen with mouse cursor. I'm not sure, but it seems I used UXA in comment #9. So, I'll try to fulfill your recommendations. Thanks!
I found interesting thing. This problem appears only when I apply a patch. If I on stock ports tree remove files/patch-src_sna_sna__video.c (for build purpose) and simply adjust port's Makefile all works fine with SNA. -GL_COMMIT= e5ff8e1828f97891c819c919d7115c6e18b2eb1f +GL_COMMIT= e628d22673dfa494230e6f79ceff7d178137c71a
I started to apply this patch line by line and found strings in Makefile that cause a problem: -USES= cpe gl xorg xorg-cat:driver +USES= cpe gl localbase xorg xorg-cat:driver
(In reply to Alexandr Krivulya from comment #29) USES=localbase is used to fix auto-detection of MIT SHM and Xinerama. Can you compare config.log before and after? I suspect bug 242236.
Created attachment 209443 [details] with localbase option
Created attachment 209444 [details] without localbase option
Created attachment 209459 [details] v7.1 (In reply to Alexandr Krivulya from comment #31) > +#define HAVE_SYS_SYSINFO_H 1 > +#define HAVE_STRUCT_SYSINFO_TOTALRAM 1 Does this version make SNA work again for you?
Yes, it works. Thank you!
Created attachment 211645 [details] v7.2 - More upstream SNA bugfixes - I did test build/runtime as usual but no longer dogfood this port (switched to Wayland) - files/patch-src_sna_kgem.c can be dropped after https://github.com/FreeBSDDesktop/kms-drm/pull/205 propagates to all graphics/drm-*-kmod ports
(In reply to Theron Tarigo from comment #18) > As long as DRM 4.9 continues to build and run on FreeBSD 12.x ... If you're still stuck on 4.9 try https://github.com/FreeBSDDesktop/kms-drm/pull/214 but I suspect your issue is probably fixed by https://github.com/FreeBSDDesktop/kms-drm/pull/205 which, unfortunately, hasn't propagated to drm-*-kmod ports yet.
LGTM But not tested, I don't really care about !modesetting.
I tested v7.2 and two or three previous versions on Intel Haswell GPU. Works without any issues. Without this patch xorg-server is unusable for me. So I like to see it commited. Thanks!
It seems like drm-*-kmod ports now have fix for I915_USERPTR_UNSYNCHRONIZED.
Created attachment 211836 [details] v7.3 Thanks for the reminder. I've dropped userptr workaround, so performance may improve.
(In reply to Jan Beich from comment #40) Tested on 12-STABLE and Haswell GPU with chromium and mpv - works great. As for me, latency was improved after removing userptr workaround. I still not ready to switch to wayland, so again, thanks for updated patch.
No, with your patches I have been able to use latest fbsd-12.0-kmod (4.12). Looks like I forgot to let you know when I first tried this and found that it is working. Also seems to work just as well with your latest patch (v7.3). I'm still using TearFree option, SNA, and no compositor daemon. The adapter is Intel(R) HD Graphics 530 (Skylake GT2) (0x191b) OpenGL works beautifully at 60fps, vsync, never tearing. However, nothing seems to play video at 60fps - Mplayer, Chromium, Firefox all drop frames, listed here in order of increasing severity. Can someone explain to me why "modesetting" is "the future" and xf86-video-intel is "legacy"? My experience has been that either Modesetting is fundamentally broken in design, or it really is just a bug for its entire existence that it allows frame-tearing. Probably not directly relevant, but both intel and modesetting waste about 4 watts of battery power compared to scfb driver, with everything else being equal, including drm module being loaded in all cases. I might actually save power overall by just using scfb and VirtualGL+Nvidia for OpenGL tasks when I need them.
(In reply to Theron Tarigo from comment #42) "Can someone explain to me why "modesetting" is "the future" and xf86-video-intel is "legacy"? My experience has been that either Modesetting is fundamentally broken in design, or it really is just a bug for its entire existence that it allows frame-tearing." My understanding was the upstream Xorg development was moving to treating modesetting as the default graphics driver, and the intel ddx will eventually be deprecated. i believe many linux distro's also have moved to make modesetting the default as well. having said that - i agree, modesetting in its current state does give sub-optimal performance. it makes sense to me that this assumption that modesetting is really where the vendors are heading should be challenged.
(In reply to Theron Tarigo from comment #42) > The adapter is Intel(R) HD Graphics 530 (Skylake GT2) (0x191b) I'm using HD 530 as well but my PCI ID is slightly different: 0x1912 > However, nothing seems to play video at 60fps - Mplayer, Chromium, Firefox all drop frames, listed here in order of increasing severity. 2160p60 works fine here in mpv (H264 via VAAPI) and Firefox (VP9 via CPU). Maybe see bug 218188, try disabling TearFree or try updating to drm-devel-kmod (requires updating kernel to -CURRENT but leave world aka base system as is to allow going back).
(In reply to Jan Beich from comment #44) Thanks, it really was bug 218188; after a workaround, Firefox works just as well as Mplayer (still with some frame drops) so I can move on to debugging just graphics. I'll try CURRENT+COMPAT_FREEBSD12 kernel and drm-devel-kmod as you suggest.
Good news and bad news. The bad news. Somewhere around this mid-April, xf86-video-intel has stopped working reliably. I tested on FreeBSD current as of r359412 (Mar. 29) and r360237 (Apr. 24). It appears that Xorg begins either spinning inside drm ioctl or hopping U-K back and forth after massive texture operations. When Xorg begins spinning, the rest of the world is still responsive and opeartional enough to kill Xorg by some SIGXCPU and SIGABRT via ssh from other machines. Curiously, the symptom hadn't been there even after installing r359412. I suspect some pkg upgrade after that is the culprit. The good news. Due to recent switching over to DRI3, the "modesetting" driver no longer exhibits "tearing" artifacts, so I can finally fall back from xf86-video-intel without sacrificing comfortability.
Created attachment 213793 [details] v8 - More upstream SNA bugfixes (In reply to Taku YAMAMOTO from comment #46) > It appears that Xorg begins either spinning inside drm ioctl or > hopping U-K back and forth after massive texture operations. Does it happen as soon as Xorg is started? If not which application causes it. Can you attach ktrace(1) or truss(1) and try decode the ioctl Xorg invokes in a busy loop? What's U-K? What do you mean by hopping? CPU usage spikes in top(1)? Did you see anything unusual in Xorg.log? Mainly look for (EE) lines. Does enablig DRI3 in xorg.conf help? xf86-video-intel defaults to DRI2 unlike modesetting. For me xf86-video-intel works fine as it did months ago.
(In reply to Jan Beich from comment #47) The U-K line looks to mean: Hopping between Userland / Kernel.
First of all, I'm glad that you haven't lost your attention on this topic! (In reply to Jan Beich from comment #47) > > It appears that Xorg begins either spinning inside drm ioctl or > > hopping U-K back and forth after massive texture operations. > > Does it happen as soon as Xorg is started? If not which application causes it. No, Xorg starts and works as normal until I start playing some videos (firefox, mplayer -vo xv or -vo gl) and keep watching for a few minutes. The duration until Xorg gets stuck varies from time to time. > What's U-K? What do you mean by hopping? CPU usage spikes in top(1)? Sorry for unclear wording. I mean that Xorg seems to call ioctl either too frequently or ioctl busy-loops inside drm (I'm not certain). > Did you see anything unusual in Xorg.log? Mainly look for (EE) lines. Nothing special. > Does enablig DRI3 in xorg.conf help? xf86-video-intel defaults to DRI2 unlike modesetting. I never thought xf86-video-intel still defaults to DRI2! I'll test the v7.3 with DRI3 enabled first, then will try v8.
(In reply to Taku YAMAMOTO from comment #46) Very interesting, I have the opposite situation. Only Intel driver + DRI2 = no tearing. My system is ThinkPad T440p with Intel Haswell, fresh 12-STABLE, patched Mesa 19.0.8, drm-fbsd12.0-kmod-4.16. All built from sources. My config is: Section "Device" Identifier "Intel Haswell IGP" BusID "PCI:0:2:0" Driver "intel" Option "AccelMethod" "sna" Option "DRI" "2" Option "HotPlug" "true" Option "TripleBuffer" "true" Option "TearFree" "true" Option "SwapbuffersWait" "true" Option "PageFlip" "true" Option "VSync" "true" EndSection What about your system details?
(In reply to Taku YAMAMOTO from comment #49) Firefox freezing up after video play may not be a driver issue because I have same issue and I use x11/nvidia-driver as my display driver.
Hi, I had set Option "DRI" "3" on two systems (Sandy Bridge, Ivy Bridge) without setting LIBGL_DRI3_ENABLE properly. I recently upgraded the Ivy Bridge system, so that the recent changes in graphics/mesa-libs triggered DRI 3 activation. Here's what now happens: After some inactivity, pressing a key powers on the monitor but the screen keeps displaying a previous state which is anterior to the last state I let the system in before being inactive (on the Ivy Bridge system, that screen is the SLiM login manager background picture). Mouse cursor moves are still visible, keyboard presses and mouse events are still received, but nothing renders on screen: I can continue to use the system but can not see what happens. The only way to resume normal rendering is to move my mouse to a corner which activates the Compiz plugin Exposé or to switch between workspaces with another Compiz plugin via a key combination. By trial and error on the two systems, I have come to the conclusion that this non-critical problem only happens with the combination of intel and DRI 3 and Compiz. By the way, I noticed the Sandy Bridge system shows 8200 FPS in glxgears, whereas the Ivy Bridge system (HD 4000, xorg-server-1.20.8,1 and mesa-dri-18.3.2_10) only shows 7600 FPS. I need to upgrade the Sandy Bridge system to see if it keeps an advantage over the Ivy Bridge system. If it does not, that would possibly mean that a performance regression happened somewhere. The Sandy Bridge system: ThinkPad T520, HD 3000, 12.0-R with xorg-server-1.18.4_11,1 and mesa-dri-18.3.2_3 The Ivy Bridge system: Optiplex 7010, HD 4000, 12.1-R with xorg-server-1.20.8,1 and mesa-dri-18.3.2_10 Keep up the great work Jan!
I have a very similar T520 (i5-2520M CPU @ 2.50GHz (2491.96-MHz K8-class CPU)) and Sandy Bridge. Running modesetting driver, mesa 19.0.8 and drm-fbsd12.0-kmod. X running with default configuration (no DEVICE congig. glxgears runs at about 6000 fps. While glxgears is not impressive, no problems so far.
Created attachment 215191 [details] v9 More SNA fixes, see https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/compare/846b53dacd96...5ca3ac1a90af
(In reply to rkoberman from comment #53) My CPU is also an "i5-2520M CPU @ 2.50GHz", so we have a similar T520, if not the same T520. I have been running modesetting for some time and it looks pretty fine to me. However, the main reason why I stick to intel is that I sometimes experience tearing with modesetting, e.g. in chromium. Steps to reproduce: 1) Go to https://www.dtelepathy.com/blog/inspiration/long-page-scrolling-designs 2) Click on a textual area or an empty space of the page 3) Long-press Page Down (until at the bottom) 4) Long-press Page Up (until at the top) 5) Repeat steps 3 and 4 several times and, while doing so, look at the left part of the orange header
Created attachment 215591 [details] Autobuild with the latest patch from Jan I recently wrote a simple shell script to automatically patch my ports tree with the latest patch from Jan ;-) I have slightly modified this script to make it useful for others in various scenarios: instructions in the first comment.
(In reply to Samy Mahmoudi from comment #52) I worked around the problem raised in comment 52 by assigning the variable LIBGL_DRI3_DISABLE the value 1 and exporting this variable before starting compiz (other programs still use DRI3).
Created attachment 215792 [details] v9.1 - Make XvMC optional: MPEG-2 is dead, modern CPUs are faster. See also https://github.com/mpv-player/mpv/commit/cbdb7e6305 - Drop libXv because it's not used directly - Drop libXext, libXrender because tools are not built/installed - Drop USE_GL per https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/commit/34b9d45be6cb Note, libXi can also be dropped but requires # Undo USES=xorg-cat:driver adding USE_XORG=xi to video drivers .include <bsd.port.pre.mk> USE_XORG:= ${USE_XORG:Nxi} .include <bsd.port.post.mk> or in Mk/Uses/xorg-cat.mk -USE_XORG+= xi xorg-server xorgproto +USE_XORG+= ${PORTNAME:M*input*:C/.+/xi/} xorg-server xorgproto
A commit references this bug: Author: zeising Date: Tue Aug 18 22:07:49 UTC 2020 New revision: 545262 URL: https://svnweb.freebsd.org/changeset/ports/545262 Log: x11-drivers/xf86-video-intel: Update snapshot Update the snapshot of x11-driver/xf86-video-intel - Fix build with -fno-common - Fix MIT-SHM detection - Drop SNA/UXA options in favor of xorg.conf(5) - Add hyphen to output names for consistency with modesetting(4x) - Add UDEV and XVMC options - Add "make test" support - Drop unused dependencies - Switch to upstream versioning scheme - Document all patches - Simplify and deprecate _WITH_GETLINE - Fix most style warnings PR: 236003 Submitted by: jbiech MFH: 2020Q3 Changes: head/x11-drivers/xf86-video-intel/Makefile head/x11-drivers/xf86-video-intel/distinfo head/x11-drivers/xf86-video-intel/files/patch-benchmarks_dri3-swap.c head/x11-drivers/xf86-video-intel/files/patch-hyphen head/x11-drivers/xf86-video-intel/files/patch-src_intel__device.c head/x11-drivers/xf86-video-intel/files/patch-src_intel__list.h head/x11-drivers/xf86-video-intel/files/patch-src_sna_kgem.c head/x11-drivers/xf86-video-intel/files/patch-src_sna_sna__threads.c head/x11-drivers/xf86-video-intel/files/patch-src_sna_sna__video.c head/x11-drivers/xf86-video-intel/files/patch-test_present-speed.c head/x11-drivers/xf86-video-intel/pkg-plist
Awaiting merge
A commit references this bug: Author: zeising Date: Wed Aug 19 08:37:02 UTC 2020 New revision: 545285 URL: https://svnweb.freebsd.org/changeset/ports/545285 Log: MFH: r545262 x11-drivers/xf86-video-intel: Update snapshot Update the snapshot of x11-driver/xf86-video-intel - Fix build with -fno-common - Fix MIT-SHM detection - Drop SNA/UXA options in favor of xorg.conf(5) - Add hyphen to output names for consistency with modesetting(4x) - Add UDEV and XVMC options - Add "make test" support - Drop unused dependencies - Switch to upstream versioning scheme - Document all patches - Simplify and deprecate _WITH_GETLINE - Fix most style warnings PR: 236003 Submitted by: jbiech Approved by: ports-secteam (joenum) Changes: _U branches/2020Q3/ branches/2020Q3/x11-drivers/xf86-video-intel/Makefile branches/2020Q3/x11-drivers/xf86-video-intel/distinfo branches/2020Q3/x11-drivers/xf86-video-intel/files/patch-benchmarks_dri3-swap.c branches/2020Q3/x11-drivers/xf86-video-intel/files/patch-hyphen branches/2020Q3/x11-drivers/xf86-video-intel/files/patch-src_intel__device.c branches/2020Q3/x11-drivers/xf86-video-intel/files/patch-src_intel__list.h branches/2020Q3/x11-drivers/xf86-video-intel/files/patch-src_sna_kgem.c branches/2020Q3/x11-drivers/xf86-video-intel/files/patch-src_sna_sna__threads.c branches/2020Q3/x11-drivers/xf86-video-intel/files/patch-src_sna_sna__video.c branches/2020Q3/x11-drivers/xf86-video-intel/files/patch-test_present-speed.c branches/2020Q3/x11-drivers/xf86-video-intel/pkg-plist
Merged