Bug 236003 - x11-drivers/xf86-video-intel: update to 2020-05-15 snapshot and refactor
Summary: x11-drivers/xf86-video-intel: update to 2020-05-15 snapshot and refactor
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
URL: https://gitlab.freedesktop.org/xorg/d...
Keywords: patch, patch-ready
Depends on: 233902
Blocks:
  Show dependency treegraph
 
Reported: 2019-02-24 17:40 UTC by Jan Beich
Modified: 2020-08-19 08:40 UTC (History)
13 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)
jbeich: merge-quarterly?


Attachments
v1 (has commit message) (23.93 KB, patch)
2019-02-24 17:40 UTC, Jan Beich
no flags Details | Diff
v2 (has commit message) (23.95 KB, patch)
2019-03-04 03:35 UTC, Jan Beich
no flags Details | Diff
v3 (has commit message) (24.00 KB, patch)
2019-07-04 01:50 UTC, Jan Beich
no flags Details | Diff
v3 (has commit message) (23.95 KB, patch)
2019-07-23 10:07 UTC, Jan Beich
no flags Details | Diff
v4 (has commit message) (24.01 KB, patch)
2019-07-30 15:51 UTC, Jan Beich
no flags Details | Diff
v4 (has commit message) (23.92 KB, patch)
2019-09-22 21:15 UTC, Jan Beich
no flags Details | Diff
v5 (has commit message) (23.89 KB, patch)
2019-09-30 11:46 UTC, Jan Beich
no flags Details | Diff
v6 (23.89 KB, patch)
2019-10-30 18:50 UTC, Jan Beich
no flags Details | Diff
v6.1 (23.94 KB, patch)
2019-11-03 23:38 UTC, Jan Beich
no flags Details | Diff
v7 (23.98 KB, patch)
2019-11-23 16:42 UTC, Jan Beich
no flags Details | Diff
with localbase option (163.32 KB, text/plain)
2019-11-26 05:34 UTC, Oleksandr Kryvulia
no flags Details
without localbase option (161.90 KB, text/plain)
2019-11-26 05:35 UTC, Oleksandr Kryvulia
no flags Details
v7.1 (24.06 KB, patch)
2019-11-26 20:37 UTC, Jan Beich
no flags Details | Diff
v7.2 (24.20 KB, patch)
2020-02-14 13:45 UTC, Jan Beich
no flags Details | Diff
v7.3 (23.57 KB, patch)
2020-02-22 15:17 UTC, Jan Beich
no flags Details | Diff
v8 (23.57 KB, patch)
2020-04-26 07:11 UTC, Jan Beich
no flags Details | Diff
v9 (23.57 KB, patch)
2020-06-03 12:00 UTC, Jan Beich
no flags Details | Diff
Autobuild with the latest patch from Jan (1.70 KB, text/plain)
2020-06-15 22:01 UTC, Samy Mahmoudi
no flags Details
v9.1 (24.51 KB, patch)
2020-06-19 15:34 UTC, Jan Beich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2019-02-24 17:40:18 UTC
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
Comment 1 Jan Beich freebsd_committer 2019-03-04 03:35:53 UTC
Created attachment 202533 [details]
v2 (has commit message)
Comment 2 Jan Beich freebsd_committer 2019-03-08 01:56:41 UTC
Am I the only user left?
Comment 3 rkoberman 2019-03-08 20:52:59 UTC
(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.
Comment 4 Steve Wills freebsd_committer 2019-04-01 16:23:01 UTC
I tested this and it seems to work fine.
Comment 5 Taku YAMAMOTO 2019-05-12 06:49:49 UTC
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.
Comment 6 Jan Beich freebsd_committer 2019-07-04 01:17:57 UTC
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.
Comment 7 Jan Beich freebsd_committer 2019-07-04 01:50:16 UTC
Created attachment 205509 [details]
v3 (has commit message)

Oops, I had an update but forgot to upload: 2 more upstream SNA fixes.
Comment 8 Jan Beich freebsd_committer 2019-07-04 01:54:12 UTC
Comment on attachment 205509 [details]
v3 (has commit message)

Nevermind. There's no difference between v2 and v3.
Comment 9 Oleksandr Kryvulia 2019-07-04 07:28:18 UTC
Works well on my Thinkpad T470p with Kaby Lake. Not tested yet with external display attached.
Comment 10 Jan Beich freebsd_committer 2019-07-23 10:07:44 UTC
Created attachment 206005 [details]
v3 (has commit message)

More upstream SNA fixes.
Comment 11 JavaShin 2019-07-25 09:48:41 UTC
Working Fine Here Thanks
Comment 12 Jan Beich freebsd_committer 2019-07-30 15:51:16 UTC
Created attachment 206160 [details]
v4 (has commit message)

More upstream SNA fixes.
Comment 13 Jan Beich freebsd_committer 2019-09-22 21:15:09 UTC
Created attachment 207727 [details]
v4 (has commit message)

Rebase after ports r509895
Comment 14 Jan Beich freebsd_committer 2019-09-30 11:46:49 UTC
Created attachment 207959 [details]
v5 (has commit message)

Upstream warning fixes.
Comment 15 Jan Beich freebsd_committer 2019-10-30 18:50:31 UTC
Created attachment 208705 [details]
v6

Upstream SNA bugfix
Comment 16 Jan Beich freebsd_committer 2019-10-30 19:19:01 UTC
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. ;\
Comment 17 Taku YAMAMOTO 2019-11-03 17:55:55 UTC
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.
Comment 18 Theron Tarigo freebsd_committer 2019-11-03 22:30:09 UTC
(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).
Comment 19 Jan Beich freebsd_committer 2019-11-03 23:18:16 UTC
(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).
Comment 20 Jan Beich freebsd_committer 2019-11-03 23:38:23 UTC
Created attachment 208834 [details]
v6.1

- Fix missing git hash in buildstring (used in Xorg.log) after ports r509895
- Rebase after ports rr516607
Comment 21 Oleh Hushchenkov 2019-11-04 09:35:44 UTC
Tested on Haswell IGPU. Fixes bug #241685. It have to be committed ASAP.

Thanks Jan!
Comment 22 JavaShin 2019-11-11 16:09:37 UTC
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
Comment 23 Oleksandr Kryvulia 2019-11-11 19:23:40 UTC
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.
Comment 24 Jan Beich freebsd_committer 2019-11-23 16:42:26 UTC
Created attachment 209362 [details]
v7

Upstream SNA bugfixes.
Comment 25 Jan Beich freebsd_committer 2019-11-23 17:02:20 UTC
(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.
Comment 26 Jan Beich freebsd_committer 2019-11-23 17:09:20 UTC
Whether comment 23 tells about regression since comment 9 is still unclear as comment 9 didn't specify which AccelMethod was tested.
Comment 27 Oleksandr Kryvulia 2019-11-24 20:46:03 UTC
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!
Comment 28 Oleksandr Kryvulia 2019-11-25 17:05:19 UTC
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
Comment 29 Oleksandr Kryvulia 2019-11-25 20:58:50 UTC
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
Comment 30 Jan Beich freebsd_committer 2019-11-25 21:59:10 UTC
(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.
Comment 31 Oleksandr Kryvulia 2019-11-26 05:34:36 UTC
Created attachment 209443 [details]
with localbase option
Comment 32 Oleksandr Kryvulia 2019-11-26 05:35:09 UTC
Created attachment 209444 [details]
without localbase option
Comment 33 Jan Beich freebsd_committer 2019-11-26 20:37:32 UTC
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?
Comment 34 Oleksandr Kryvulia 2019-11-27 08:59:56 UTC
Yes, it works. Thank you!
Comment 35 Jan Beich freebsd_committer 2020-02-14 13:45:10 UTC
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
Comment 36 Jan Beich freebsd_committer 2020-02-17 08:08:44 UTC
(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.
Comment 37 Emmanuel Vadot freebsd_committer 2020-02-17 17:08:41 UTC
LGTM
But not tested, I don't really care about !modesetting.
Comment 38 Oleh Hushchenkov 2020-02-17 17:25:03 UTC
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!
Comment 39 Oleh Hushchenkov 2020-02-22 14:46:57 UTC
It seems like drm-*-kmod ports now have fix for I915_USERPTR_UNSYNCHRONIZED.
Comment 40 Jan Beich freebsd_committer 2020-02-22 15:17:58 UTC
Created attachment 211836 [details]
v7.3

Thanks for the reminder. I've dropped userptr workaround, so performance may improve.
Comment 41 Oleh Hushchenkov 2020-02-22 15:41:56 UTC
(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.
Comment 42 Theron Tarigo freebsd_committer 2020-02-26 03:48:05 UTC
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.
Comment 43 pete 2020-02-26 04:15:59 UTC
(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.
Comment 44 Jan Beich freebsd_committer 2020-02-26 20:19:51 UTC
(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).
Comment 45 Theron Tarigo freebsd_committer 2020-02-26 20:59:44 UTC
(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.
Comment 46 Taku YAMAMOTO 2020-04-26 06:12:55 UTC
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.
Comment 47 Jan Beich freebsd_committer 2020-04-26 07:11:44 UTC
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.
Comment 48 Chris Hutchinson 2020-04-26 07:46:43 UTC
(In reply to Jan Beich from comment #47)
The U-K line looks to mean:
Hopping between Userland / Kernel.
Comment 49 Taku YAMAMOTO 2020-04-26 07:48:35 UTC
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.
Comment 50 Oleh Hushchenkov 2020-04-26 10:05:33 UTC
(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?
Comment 51 aryeh.friedman 2020-04-26 23:15:06 UTC
(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.
Comment 52 Samy Mahmoudi 2020-05-05 14:12:08 UTC
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!
Comment 53 rkoberman 2020-05-05 16:41:34 UTC
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.
Comment 55 Samy Mahmoudi 2020-06-15 20:55:42 UTC
(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
Comment 56 Samy Mahmoudi 2020-06-15 22:01:15 UTC
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.
Comment 57 Samy Mahmoudi 2020-06-15 22:26:59 UTC
(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).
Comment 58 Jan Beich freebsd_committer 2020-06-19 15:34:10 UTC
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
Comment 59 commit-hook freebsd_committer 2020-08-18 22:08:06 UTC
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
Comment 60 Niclas Zeising freebsd_committer 2020-08-18 22:08:23 UTC
Awaiting merge
Comment 61 commit-hook freebsd_committer 2020-08-19 08:37:08 UTC
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
Comment 62 Niclas Zeising freebsd_committer 2020-08-19 08:40:16 UTC
Merged