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.
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
- working Vulkan on AMD and partially working on Intel
 UXA (default due to legacy DRM) is slow while modesetting(4x) incurs flickering/stutter when switching workspaces back and forth here
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.