Bug 230298
| Summary: | graphics/mesa-dri: update to 18.2.8 | ||||||
|---|---|---|---|---|---|---|---|
| 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, pi, rkoberman, zeising | ||||
| Priority: | --- | Keywords: | patch | ||||
| Version: | Latest | Flags: | imp:
maintainer-feedback+
|
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| URL: | https://www.mesa3d.org/relnotes/18.2.8.html | ||||||
| See Also: | https://bugzilla.mozilla.org/show_bug.cgi?id=1543217 | ||||||
| Bug Depends on: | 227423, 227685 | ||||||
| Bug Blocks: | 233034 | ||||||
| Attachments: |
|
||||||
|
Description
Jan Beich
2018-08-02 18:01:32 UTC
This is still in RC, not ready to land in the ports tree yet. Let's start the clock ticking. This is not approved. There are still some questions regarding regressions on the x11@ mailing list. 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). 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. (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. @zeising, did you finish review or are off to another conference? 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). 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. 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. 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. (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. 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. (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. (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) (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. 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.
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. 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.) Mesa 18.2.* effectively reached EOL. 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 Also required by Firefox 68+ for WebRender. https://www.reddit.com/r/firefox/comments/bc4ci3/webrender_enabled_by_default_on_linux_nightly/ |