Bug 233034 - graphics/mesa-dri: update to 18.3.2
Summary: graphics/mesa-dri: update to 18.3.2
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 mailing list
URL: https://www.mesa3d.org/relnotes/18.3....
Keywords: needs-qa, patch
Depends on: 235487 230298 234891
Blocks: 235570
  Show dependency treegraph
 
Reported: 2018-11-06 17:53 UTC by Jan Beich
Modified: 2019-02-07 11:05 UTC (History)
4 users (show)

See Also:


Attachments
Image of corrupt wallpaper with mesa-18.3.1 (410.10 KB, image/png)
2019-01-02 19:08 UTC, rkoberman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer 2018-11-06 17:53:50 UTC
See review D17872 for the patch. Call for testing and maintainer timeout countdown are blocked until actual release. Schedule your review appropriately.

Let the coordination happen here.
Comment 1 Niclas Zeising freebsd_committer 2018-12-07 12:19:44 UTC
The Graphics Team decided to push off releasing this to the ports tree until after 2019Q1 is branched.
Comment 2 Jan Beich freebsd_committer 2018-12-07 12:33:08 UTC
"Decided"? Are you implying it's fine to land as soon as 2019Q1 branches to maximize post-CFT testing and minimize MFH churn?
Comment 3 Warner Losh freebsd_committer 2018-12-07 18:54:25 UTC
Since 12.0 isn't out, it's easier to manage things if we wait to commit this. Once it's out, the Q1 branch point is a convenient time to commit. People tracking the Q1 branch can live with the slightly old, but still fully functional release. If some security issue comes up and there's no patches to the current version, we can fall back to merging 18.3 to the Q1 branch. The risk is that we break things. While this has been tested on some intel hardware, we need to make sure we don't break amdgpus and that it works well with the latest drm-kmod modules. Given the critical nature of the mesa, we need positive reports of working on a variety of hardware which we don't yet have.
Comment 4 Jan Beich freebsd_committer 2018-12-08 18:58:28 UTC
(In reply to Warner Losh from comment #3)
> Since 12.0 isn't out, it's easier to manage things if we wait to commit this.

Mesa upstream appears to release new minor version every ~3 months. If 18.3.* doesn't land in ports early 2019Q1 its QA is likely to intersect with 18.4.0 (or 19.0.0). Part of QA is whatching bugzilla/lists/etc for regressions after landing, reported by users experienced enough to switch to /latest. Besides, doing updates in small/incremental steps is easier than waiting then skipping over versions which increases the risk and complicates regression tracking.

> make sure we don't break amdgpus

Similar to Intel, depends on the kernel driver: radeonkms (legacy) is probably under the most risk. Otherwise, see https://lists.freebsd.org/pipermail/freebsd-x11/2018-December/022256.html

> it works well with the latest drm-kmod modules

drm-stable-kmod is probably more important:
- selected by drm-kmod for 11.2 or /stable/11
- working SNA on xf86-video-intel[1]
- working Vulkan on AMD[2] and partially working on Intel[3]

[1] UXA (default due to legacy DRM) is slow while modesetting(4x) incurs flickering/stutter when switching workspaces back and forth here
[2] https://github.com/FreeBSDDesktop/kms-drm/issues/33
[3] https://github.com/FreeBSDDesktop/DEPRECATED-freebsd-base-graphics/issues/132
    https://bugs.freebsd.org/bugzilla/attachment.cgi?id=187401
Comment 5 rkoberman 2018-12-08 21:21:38 UTC
Tested on Intel HD3000 (Sandybridge) and all is working fine so far.

glgears just under 5000 with no vsync (60 FPS with)
mpv plays back 1080p video with acceleration and minimal CPU (using libva-intel-driver)
firefox runs with acceleration and webrender once I get the command typed correctly.

So far, I see no issues at all, but I just started running it about 6 hours ago with little requirement for it other than the tests. I'll follow up if any sign of a regression shows up. Running 11.2-STABLE FreeBSD 11.2-STABLE #0 r338990.

I expect to be moving to 12.0 soon, so ability to test on 11.2 will be gone, I'm afraid. I usually move to the new version as soon as beta starts, but have just been too busy.
Comment 6 Jan Beich freebsd_committer 2019-01-01 03:47:58 UTC
2019Q1 has branched in ports r488858. Any other blockers?
Comment 7 rkoberman 2019-01-02 19:08:56 UTC
Created attachment 200723 [details]
Image of corrupt wallpaper with mesa-18.3.1

With mesa-18.3.1 I am periodically seeing the corruption to my wallpaper demonstrated in the image attached. I do not see this with the mesa in ports, though I have also updated libva-intel-driver-2.3.0 to include hybrid. It just looks a bit more likely that mesa is the cause.

System is FreeBSD 12.0-STABLE r342382 running on amd64 on a Sandy Bridge system.

Once the corruption appears, reloading the wallpaper momentarily corrects it, but the corruption almost immediately reappears. Restarting X will restore the wallpaper for an extended time until some unknown event triggers it again. I have had it go for several hours before reappearing.

I will attempt to figure out what triggers the problem. This was not happening while running the ports version of mesa (18.1.9). I never saw it with mesa-18.2.8. I will fall back to that if I can find a reliable trigger.
Comment 8 Greg V 2019-01-02 19:23:16 UTC
(In reply to rkoberman from comment #7)

Are you using xf86-video-intel or modesetting? Does the problem happen on the other one that you're currently on?
Comment 9 rkoberman 2019-01-02 20:58:15 UTC
(In reply to Greg V from comment #8)
I'm sure that I should know what triggers the selection of modesetting vs.xf86-intel. In my log I see all possible drivers loaded and then the following:

[    90.970] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20171222
[    90.971] (WW) Falling back to old probe method for modesetting
[    90.971] (WW) Falling back to old probe method for scfb
[    90.971] scfb trace: probe start
[    90.971] scfb trace: probe done
[    90.971] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[    90.972] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000
[    90.973] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx; using a maximum of 2 threads
[    90.973] (II) intel(0): Creating default Display subsection in Screen section
        "Screen0" for depth/fbbpp 24/32
[    90.973] (**) intel(0): Depth 24, (--) framebuffer bpp 32
[    90.973] (==) intel(0): RGB weight 888
[    90.973] (==) intel(0): Default visual is TrueColor
[    91.004] (II) intel(0): Output LVDS1 has no monitor section
[    91.004] (II) intel(0): Enabled output LVDS1
[    91.004] (II) intel(0): Output VGA1 has no monitor section
[    91.004] (II) intel(0): Enabled output VGA1
[    91.004] (II) intel(0): Output HDMI1 has no monitor section
[    91.004] (II) intel(0): Enabled output HDMI1
[    91.005] (II) intel(0): Output DP1 has no monitor section
[    91.005] (II) intel(0): Enabled output DP1
[    91.005] (II) intel(0): Output HDMI2 has no monitor section
[    91.005] (II) intel(0): Enabled output HDMI2
[    91.005] (II) intel(0): Output HDMI3 has no monitor section
[    91.005] (II) intel(0): Enabled output HDMI3
[    91.005] (II) intel(0): Output DP2 has no monitor section
[    91.005] (II) intel(0): Enabled output DP2
[    91.005] (II) intel(0): Output DP3 has no monitor section
[    91.005] (II) intel(0): Enabled output DP3
[    91.005] (--) intel(0): Using a maximum size of 256x256 for hardware cursors
[    91.005] (II) intel(0): Output VIRTUAL1 has no monitor section
[    91.005] (II) intel(0): Enabled output VIRTUAL1
[    91.005] (--) intel(0): Output LVDS1 using initial mode 1600x900 on pipe 0
[    91.006] (==) intel(0): TearFree disabled
[    91.006] (==) intel(0): DPI set to (96, 96)
[    91.006] (II) Loading sub module "dri3"
[    91.006] (II) LoadModule: "dri3"
[    91.006] (II) Module "dri3" already built-in
[    91.006] (II) Loading sub module "dri2"
[    91.006] (II) LoadModule: "dri2"
[    91.006] (II) Module "dri2" already built-in
[    91.006] (II) Loading sub module "present"
[    91.006] (II) LoadModule: "present"
[    91.006] (II) Module "present" already built-in
[    91.006] (II) Module "present" already built-in
[    91.006] (II) UnloadModule: "modesetting"
[    91.006] (II) Unloading modesetting
[    91.006] (II) UnloadModule: "scfb"
[    91.006] (II) Unloading scfb
[    91.006] (II) UnloadModule: "vesa"
[    91.006] (II) Unloading vesa
[    91.006] (II) UnloadModule: "modesetting"
[    91.006] (II) Unloading modesetting
[    91.006] (II) UnloadModule: "scfb"
[    91.006] (II) Unloading scfb
[    91.006] (II) UnloadModule: "vesa"
[    91.006] (II) Unloading vesa

and that leaves the xf86-intel-driver. Do I need to put something in the conf file to cause modesetting to be selected? I see nothing to indicate a problem (except that one warning) to cause modesetting to be rejected, so I assume that X thinks that the xf86-intel-deriver should be preferred.

Probably unrelated, 32 seconds after Xorg starts, I get the following:
[   125.009] (EE) intel(0): Failed to submit rendering commands (Bad address), disabling acceleration.

I can confirm that VAAPI is no longer working, but it was not working without HYBRID and with mesa-18.1.9. I suspect that it has worked since I upgraded to 12.0. But that is probably for another ticket.
Comment 10 Greg V 2019-01-02 21:02:37 UTC
(In reply to rkoberman from comment #9)
If you do have an xorg.conf, you need

Driver "modesetting"
Option "AccelMethod" "glamor"
Option "DRI" "3"

in the Device section, instead of "intel"

If you don't have an xorg.conf.. just uninstall xf86-video-intel :)
Comment 11 rkoberman 2019-01-02 21:19:16 UTC
(In reply to Greg V from comment #10)
Thank you!

This has, at least, fixed the failure of acceleration. VAAPI is working again. Now to let sometime pass and see if the other issues are fixed.

Any plans to make modesetting preferred? Or let the "typical" user know that xf86-video-intel should not be used on 12 if modesetting works?
Comment 12 Jan Beich freebsd_committer 2019-01-02 23:31:00 UTC
(In reply to rkoberman from comment #9)
> Probably unrelated, 32 seconds after Xorg starts, I get the following:
> [   125.009] (EE) intel(0): Failed to submit rendering commands (Bad address), disabling acceleration.

intel(4x) has SNA regression on drm > v4.9, see https://github.com/FreeBSDDesktop/kms-drm/issues/32
UXA (default) is not affected but is also slower than modesetting(4x).

> Any plans to make modesetting preferred?

Probably depends on drm-legacy-kmod.
Comment 13 Niclas Zeising freebsd_committer 2019-01-02 23:39:55 UTC
(In reply to Jan Beich from comment #12)


>> Any plans to make modesetting preferred?

> Probably depends on drm-legacy-kmod.

By default the intel (or amd) driver aren't installed, so modesetting will be used.
Comment 14 rkoberman 2019-01-03 03:19:47 UTC
(In reply to Niclas Zeising from comment #13)
This is an ongoing issue with ports.Defaults change, but the saved configuration does not, so those using ports, as I do on my development system, receive no indication of this and, as a result, things go wrong.

This happened a late last year when VIMAGE was made default to allow it to work with 12, but if you just rebuilt the port, the new default did not apply,and it crashed upon start of the GUI manager.
Comment 15 commit-hook freebsd_committer 2019-01-17 15:35:32 UTC
A commit references this bug:

Author: jbeich
Date: Thu Jan 17 15:34:57 UTC 2019
New revision: 490570
URL: https://svnweb.freebsd.org/changeset/ports/490570

Log:
  graphics/mesa-{libs,dri}: update to 18.3.2

  Changes:	https://www.mesa3d.org/relnotes/18.3.0.html
  Changes:	https://www.mesa3d.org/relnotes/18.3.1.html
  Changes:	https://www.mesa3d.org/relnotes/18.3.2.html
  PR:		233034
  Tested by:	Kevin Oberman
  Approved by:	maintainer timeout (2 weeks after 2019Q1)
  Differential Revision:	https://reviews.freebsd.org/D17872

Changes:
  head/graphics/mesa-dri/Makefile.common
  head/graphics/mesa-dri/distinfo
  head/graphics/mesa-dri/files/configure.ac
  head/graphics/mesa-dri/files/patch-compat-include-guards
  head/graphics/mesa-dri/files/patch-configure
  head/graphics/mesa-dri/files/patch-src_amd_vulkan_radv__device.c
  head/graphics/mesa-dri/files/patch-src_intel_tools_aub__mem.c
  head/graphics/mesa-dri/files/patch-src_intel_tools_aubinator.c
  head/graphics/mesa-dri/files/patch-src_intel_vulkan_anv__device.c
  head/graphics/mesa-dri/files/patch-src_util_u__thread.h
  head/graphics/mesa-dri/pkg-plist
Comment 16 Jan Beich freebsd_committer 2019-01-31 19:31:13 UTC
No reported regressions after 2 weeks.