Bug 230298 - graphics/mesa-dri: update to 18.2.8
Summary: graphics/mesa-dri: update to 18.2.8
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.2....
Keywords: patch
Depends on: 227423 227685
Blocks: 233034
  Show dependency treegraph
 
Reported: 2018-08-02 18:01 UTC by Jan Beich
Modified: 2019-04-13 05:41 UTC (History)
4 users (show)

See Also:
imp: maintainer-feedback+


Attachments
drm related error messages (2.94 KB, text/plain)
2018-10-27 22:13 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-08-02 18:01:32 UTC
See review D16571 for the patch.
Comment 1 Niclas Zeising freebsd_committer 2018-08-02 18:11:32 UTC
This is still in RC, not ready to land in the ports tree yet.
Comment 2 Jan Beich freebsd_committer 2018-09-07 23:29:23 UTC
Let's start the clock ticking.
Comment 3 Niclas Zeising freebsd_committer 2018-09-17 20:53:38 UTC
This is not approved.  There are still some questions regarding regressions on the x11@ mailing list.
Comment 4 Jan Beich freebsd_committer 2018-09-17 21:03:55 UTC
What regressions? Only one user offered to help testing only to discover generic shortcomings of FreeBSD graphics stack on drm-legacy (other versions are N/A on 11.1).
Comment 5 Niclas Zeising freebsd_committer 2018-09-17 21:12:51 UTC
These are the ones I'm talking about.  In general, it's been only lightly tested, I haven't had time to look through this myself properly as well.
EuroBSDCon is this week, I'm busy with that, I don't see why we can't hold off on this for a week or two more, to get it at least a little more well-tested.
Comment 6 Jan Beich freebsd_committer 2018-09-21 17:09:53 UTC
(In reply to Niclas Zeising from comment #5)
> These are the ones I'm talking about.

Known unknowns?

> In general, it's been only lightly tested,

What can you expect from volunteers? Mesa updates aren't exactly exciting. However, updating frequently allows to catch regressions early, test reverting stuff or ask upstream for help while responsible folks are still active and their memory is fresh. Being available to fix regressions after landing is sometimes more important than how much testing was done locally.

> I haven't had time to look through this myself properly as well.

Like in bug 227423? I'm not expecting much.

> I don't see why we can't hold off on this for a week or two more, to get it at least a little more well-tested.

OK. Landing now would require backporting patch-level updates to 2018Q4. The best time is shortly after 2018Q4, earning the full cycle of testing to sort any issues out. Even then it'd be nice to MFH mesa-dri-18.1.9 culminating the (upstream) testing of 18.1 branch.
Comment 7 Jan Beich freebsd_committer 2018-10-05 14:30:34 UTC
@zeising, did you finish review or are off to another conference?
Comment 8 Jan Beich freebsd_committer 2018-10-16 09:24:13 UTC
maintainer-feedback- means maintainer timeout or did you not read the tooltip? If you mean to reject it (i.e., not grant approval) then your rationale has never been stated (other than your own lack of time).
Comment 9 Warner Losh freebsd_committer 2018-10-16 15:38:47 UTC
The rationale for the rejection seems clear to me: He's stated that the new MESA hasn't been tested. There's efforts under way to get a test suite in place to rectify that problem. There's a large impact when bad versions of this get committed, and there's been no articulated reasons why a new version is needed. This close to a FreeBSD release, we should be conservative in how we approach this and make sure things work. The x11 folks have a lot of things to coordinate, please be cooperative with them in this area, as it makes life easier for everybody.

So please consider this a very strong suggestion from someone very senior in the project to not commit this over what appear to be the explicit objections of the maintainer. There's consequences for the project in doing this, as we've learned in the past, so please err on the side of caution.
Comment 10 Warner Losh freebsd_committer 2018-10-16 15:41:59 UTC
It's clear maintainer feedback has been provided, so there's no clock ticking, this PR has been explicitly NAK'd. Confusing that you set maintainer feedback to '+' for this, but there you go.
Comment 11 Warner Losh freebsd_committer 2018-10-16 15:45:54 UTC
Also, migrating to a new version of MESA may muddy the waters for the drm to ports conversion we're undergoing, and there's enough bumps there as it is. More support load from a foreseeable issue isn't going to help those efforts.
Comment 12 Jan Beich freebsd_committer 2018-10-19 21:23:36 UTC
(In reply to Warner Losh from comment #9)
> The rationale for the rejection seems clear to me: He's stated that the new
> MESA hasn't been tested.

- there was public call for testing on ports@ + x11@ mailing lists; only 1 user heeded it but didn't confirm if anything has regressed or not (compared to have never worked on the specific hardware/drm version)
- x11@ team QA is opaque i.e., not clear how their testing is better or why shoving patches to an external repo would magically attract testers

> There's efforts under way to get a test suite in place to rectify that
> problem.

How a test suite is going to help with the lack of GPU variety? IIRC, one of the *former* x11@ peers had a lab of hardware to test things against but didn't last long as such a job isn't fun for a volunteer.

> and there's been no articulated reasons why a new version is needed.

- New hardware support
- Support for newer OpenGL versions
- Better Vulkan support
- Better support for new LLVM versions 
- Upstream support
  (Mesa 18.1.* reached EOL after 18.2.1 release;
   LLVM 6 reached EOL after LLVM 7 release)

FreeBSD only has one Mesa version in ports tree atm, and it has to support everything: from ancient hardware on the oldest FreeBSD version to the shiny new stuff on -CURRENT. Old users maybe complacent with what little features FreeBSD currently provides but new users want more, often stuff available as a given on Linux. Perfect stability is hard to reach without telemetry, anyway.

> This close to a FreeBSD release, we should be conservative in how we approach
> this and make sure things work.

MFH to 2018Q4 isn't planned here. Are you implying FreeBSD 12.0 will not ship before 2019Q1? Otherwise, /quarterly is a moving target and keeping POLA while backporting regressions is a usual occurence but the state is reset each cycle/quarter (along with binary packages).

(In reply to Warner Losh from comment #10)
> Confusing that you set maintainer feedback to '+' for this, but there you go.

maintainer-approval is an attachment flag unlike maintainer-feedback which is a bug flag. Mesa 18.2 is a moving target, so there's no attachment. I've requested review (not approval) since the first RC to give x11@ team plenty of time but so far have received only some homework questions that don't count as review, much less testing.

(In reply to Warner Losh from comment #11)
> Also, migrating to a new version of MESA may muddy the waters for the drm to ports conversion we're undergoing,

drm-legacy-kmod doesn't support FreeBSD < 12, so this has always been the case.
Comment 13 rkoberman 2018-10-27 03:21:40 UTC
Significant issue just cropped up with mesa-dri-18.2.3. It appears that VAAPI is not working. When I play a 1920x1080 video, the video is "jumpy" and the CPU use is high. When I switch back to the old version, the CPU use is down and the video plays normally.

Both versions were built with VAAPI and neither WAYLAND or VDPAU. Both running with xf86-video-intel-2.99.917.20180906. All ports are current except for that one.
Comment 14 Jan Beich freebsd_committer 2018-10-27 04:41:33 UTC
(In reply to rkoberman from comment #13)
Any difference from vainfo (from libva-utils) and eglinfo/glxinfo (from mesa-demos) between mesa-dri versions? Assuming "mpv --hwdec=vaapi" (or --hwdec=auto) try separately --gpu-context=x11 and --vo=vaapi which maybe a workaround.
Comment 15 Jan Beich freebsd_committer 2018-10-27 04:45:55 UTC
(In reply to Jan Beich from comment #14)
> --gpu-context=x11

Oops, ignore this one. It will disable VAAPI as only EGL interop is available.

$ mpv --gpu-hwdec-interop=help
Available hwdecs:
    vaapi-egl
    vdpau-glx
    drmprime-drm
    auto (behavior depends on context)
    all (load all hwdecs)
    no (do not load any and block loading on demand)
Comment 16 rkoberman 2018-10-27 06:36:26 UTC
(In reply to Jan Beich from comment #14)
I had already noted that glxgears was running slightly slower (5K vs. 4.5K FPS) with 18.2.3.  I will do further testing tomorrow.

I have built packages of both versions. so switching back an forth is mostly a matter of restarting X.
Comment 17 rkoberman 2018-10-27 22:13:33 UTC
Created attachment 198698 [details]
drm related error messages

This was all a false positive. There is no issue with mesa-18.2.3 and VAAPI. There was a DRM or hardware or driver issue, but it is VERY fuzzy.

I ran some tests on 18.1.9 and then re-installed 18.2.3. It ran almost identically to the old version. Low CPU. Smooth video. Moderate decline in glxgears FPS. Went back and forth a couple of time with no problems seen. After some head scratching, I took a look at my logs and I suspect that I see a big clue. (See attachment.) I can assure you that I was not doing anything at 4:04 and nothing special was scheduled at that time.

Looks like something hiccuped and left the GPU or the software in a condition that acceleration with VAAPI did not work. Maybe most or all  all graphics was being handed in software, though that is really a guess. I am unable to find the dump referenced in the log. And, maybe these errors are not related to the problem at all. These were all logged after my initial testing, which seemed to go well, and the problem I saw this week.

If I should open a ticket for the issue logged, let me know and also let me know what, if anything, I should attach or try. I'll admit cluelessness.
Comment 18 Jan Beich freebsd_committer 2018-10-28 05:43:01 UTC
Thanks for the followup. If you can't reproduce reliably then we're back to unknown if there're any regressions.

(In reply to rkoberman from comment #17)
> Looks like something hiccuped and left the GPU or the software in
> a condition that acceleration with VAAPI did not work.

I've seen something similar after GPU overclocking, unstable drm-next revisions, etc. Often restarting Xserver helps but not always. For me, intel DDX with drm-v4.11 or drm-v4.16 often screws GPU enough that OpenGL doesn't work until reboot.
Comment 19 rkoberman 2018-10-28 17:17:53 UTC
I have been seeing this error ever since my initial use of power management in i915kms long ago. Whatever this is, it is almost certainly not tied to the mesa update. Usually it shows up with a multi-second graphics freeze and no other obvious issues, but it is entirely possible that the loss of video acceleration had been caused by this for a long time and I just have not noticed as I only have been running with acceleration for a fairly short time. (I believed the documentation that said that it only was used on Radeon graphics.)
Comment 20 Jan Beich freebsd_committer 2018-12-27 19:24:05 UTC
Mesa 18.2.* effectively reached EOL.
Comment 21 commit-hook freebsd_committer 2019-01-17 15:35:29 UTC
A commit references this bug:

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

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

  - TEXTURE option is always enabled per
    https://cgit.freedesktop.org/mesa/mesa/commit/?id=66673bef941a

  Changes:	https://www.mesa3d.org/relnotes/18.2.0.html
  Changes:	https://www.mesa3d.org/relnotes/18.2.1.html
  Changes:	https://www.mesa3d.org/relnotes/18.2.2.html
  Changes:	https://www.mesa3d.org/relnotes/18.2.3.html
  Changes:	https://www.mesa3d.org/relnotes/18.2.4.html
  Changes:	https://www.mesa3d.org/relnotes/18.2.5.html
  Changes:	https://www.mesa3d.org/relnotes/18.2.6.html
  Changes:	https://www.mesa3d.org/relnotes/18.2.7.html
  Changes:	https://www.mesa3d.org/relnotes/18.2.8.html
  PR:		230298
  Tested by:	Samy Mahmoudi, Kevin Oberman
  Approved by:	maintainer timeout (2 weeks after 2019Q1)
  Differential Revision:	https://reviews.freebsd.org/D16571

Changes:
  head/graphics/mesa-dri/Makefile
  head/graphics/mesa-dri/Makefile.common
  head/graphics/mesa-dri/distinfo
  head/graphics/mesa-dri/files/configure.ac
  head/graphics/mesa-dri/files/patch-configure
  head/graphics/mesa-dri/files/patch-llvm7
  head/graphics/mesa-dri/files/patch-src_intel_tools_aubinator.c
  head/graphics/mesa-dri/files/patch-src_intel_tools_aubinator__error__decode.c
  head/graphics/mesa-dri/files/patch-src_intel_tools_error2aub.c
  head/graphics/mesa-dri/files/patch-src_util_build__id.c
  head/graphics/mesa-dri/pkg-help
  head/graphics/mesa-dri/pkg-plist
  head/graphics/mesa-libs/Makefile
  head/graphics/mesa-libs/pkg-plist
Comment 22 Jan Beich freebsd_committer 2019-04-13 05:41:00 UTC
Also required by Firefox 68+ for WebRender.
https://www.reddit.com/r/firefox/comments/bc4ci3/webrender_enabled_by_default_on_linux_nightly/