Bug 233034
| Summary: | graphics/mesa-dri: update to 18.3.2 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jan Beich <jbeich> | ||||
| Component: | Individual Port(s) | Assignee: | freebsd-x11 (Nobody) <x11> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | imp, rkoberman, val, zeising | ||||
| Priority: | --- | Keywords: | needs-qa, patch | ||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| URL: | https://www.mesa3d.org/relnotes/18.3.2.html | ||||||
| Bug Depends on: | 230298, 234891, 235203, 235487 | ||||||
| Bug Blocks: | 235570 | ||||||
| Attachments: |
|
||||||
|
Description
Jan Beich
2018-11-06 17:53:50 UTC
The Graphics Team decided to push off releasing this to the ports tree until after 2019Q1 is branched. "Decided"? Are you implying it's fine to land as soon as 2019Q1 branches to maximize post-CFT testing and minimize MFH churn? 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. (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 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. 2019Q1 has branched in ports r488858. Any other blockers? 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.
(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? (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. (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 :) (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? (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. (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. (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. 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 No reported regressions after 2 weeks. |