Created attachment 184678 [details] rc1 Minor releases (a la semver) have medium risk of runtime regressions. Let's piece together the puzzle of QA e.g., - mesa-{libs,dri}, libosmesa, clover: build fine on 10.3 i386/amd64, 11.0 i386/amd64, 12.0 i386/amd64 - mesa-{libs,dri} builds fine on 11.1 aarch64 (no armv6 due to bug 220542) - mesa-dri + llvm39 builds fine on 12.0 amd64 (llvm50 is N/A atm) - mesa-dri + TEXTURE=off + VAAPI=on + VDPAU=on builds fine on 10.3 i386 - mesa-libs + WAYLAND=on builds fine on 10.3 i386 (see bug 220981) - OpenGL and VAAPI apps work fine on i965/skl + X11+DRI3 on 12.0+drm-next amd64 https://lists.freedesktop.org/archives/mesa-dev/2017-July/164195.html
Any clue when devel/llvm50 is going to be available in the ports? According to llvm.org schedule rc1 should've appeared a few days ago. devel/llvm-devel is currently too old to be of much use. 12.0-CURRENT has Clang 5.0 since base r321369, so it'd be nice to check LLVM 5.0 fallout via Mesa, Beignet, Firefox (Stylo), Rust, etc.
Created attachment 184874 [details] rc2 https://lists.freedesktop.org/archives/mesa-dev/2017-July/164726.html
Comment on attachment 184874 [details] rc2 Oops, armv6 is busted after https://cgit.freedesktop.org/mesa/mesa/commit/?id=a373f77662c5 =======================<phase: patch >============================ ===> Patching for mesa-dri-17.2.0.rc2 ===> Applying extra patch /usr/ports/graphics/mesa-dri/files/extra-src_gallium_drivers_vc4_Makefile.in 1 out of 1 hunks failed--saving rejects to src/gallium/drivers/vc4/Makefile.in.rej *** Error code 1
Created attachment 185043 [details] rc2 The existing NEON fix was incomplete: - never used on aarch64 or FreeBSD armv6 - pessimized for CPUTYPE > armv7-a (e.g., armv7ve or armv8*) build logs after: - head-armv6 - http://sprunge.us/FQET - head-aarch64 - http://sprunge.us/DhPL
Created attachment 185044 [details] rc2
Created attachment 185045 [details] rc2 Oops, NEON was still disabled on aarch64 but it's not really compatible (see below). Dropping aarch64-specific changes. In file included from vc4_tiling_lt_neon.c:30: ./vc4_tiling_lt.c:84:27: error: unknown register name 'q0' in asm : "q0", "q1", "q2", "q3"); ^ ./vc4_tiling_lt.c:106:27: error: unknown register name 'q0' in asm : "q0", "q1", "q2", "q3"); ^ ./vc4_tiling_lt.c:141:27: error: unknown register name 'q0' in asm : "q0", "q1", "q2", "q3"); ^ ./vc4_tiling_lt.c:161:27: error: unknown register name 'q0' in asm : "q0", "q1", "q2", "q3"); ^ 4 errors generated.
Created attachment 185138 [details] rc3 (final) https://lists.freedesktop.org/archives/mesa-dev/2017-August/165750.html According the schedule during -rc1 announcement this one is supposed to be final candidate. As usual, tested per comment 0 menu with more focus on armv6/aarch64. MESA_LLVM_VER=50 state is still unknown as devel/llvm-devel is too old.
Created attachment 185340 [details] rc4 https://lists.freedesktop.org/archives/mesa-dev/2017-August/166189.html - Switch to __ELF_WORD_SIZE for Elf{32,64} types.
Created attachment 185642 [details] rc5 https://lists.freedesktop.org/archives/mesa-dev/2017-August/166916.html
Created attachment 186074 [details] release
Starting Xorg with 17.2.0 (this "release" patch + Vulkan patch) on amdgpu (Radeon RX 480, 12-CURRENT built today (git rev b2f0b570ad4), drm-next-kmod port) results in glitch art instead of display output and the following text repeatedly spammed into console: .AMDGPU.config is empty! radeonsi: cannot read an ELF shader binary LLVM failed to compile shader Works fine on Intel Haswell though.
(In reply to Greg V from comment #11) > .AMDGPU.config is empty! > radeonsi: cannot read an ELF shader binary > LLVM failed to compile shader Not sure why mesa-dri-17.1.7 works fine for you despite https://cgit.freedesktop.org/mesa/mesa/commit/?id=c968de198902 Can you try reverting that commit? Can you try reverting graphics/mesa-dri/files/patch-src_util_build__id.c ? Can you check if MESA_LLVM_VER=39 is affected as well?
(In reply to Jan Beich from comment #12) MESA_LLVM_VER=39, MESA_LLVM_VER=-devel — same problem. Reverting that commit results in a black screen and then terminal instead of Xorg. Also just built 17.1.8 from ports… same problem! So it's not 17.2.0 related. Probably some weird incompatibility between downloaded pkgs and ports built on my machine… I've had that kind of issue with Intel in the past.
(In reply to Greg V from comment #13) Okay, so there is some weird problem with builds on my desktop. 17.1.7 built here also glitches. Took 17.2.0+Vulkan packages built on my laptop and copied them to the desktop — it works!
mesa-dri-17.2.0 builds fine against llvm50.
Created attachment 186494 [details] release, v2 https://lists.freedesktop.org/archives/mesa-dev/2017-September/169968.html
Tested 17.2.1 with llvm50 on AMD Polaris10 and Intel Haswell, works fine.
No one has tested on current FreeBSD *releases* yet. ports r443828 doesn't inspire confidence *minor* Mesa updates are safe with old kernel DRM code.
Carlos, can you check i965 from Mesa 17.2 works fine for you on FreeBSD 10.* ? Try running mpv, chromium and a 3D game.
Mikhail, can you check r300 from Mesa 17.2 works fine for you on FreeBSD 10.* ? Try running mplayer (-vo gl), firefox (with/without OpenGL compositing) and a 3D game.
(In reply to Jan Beich from comment #19) It works fine for me. Chromium and MPV run properly. I didn't notice any regression at the moment.
Created attachment 186599 [details] glxinfo-mesa-17.2.1
Created attachment 186873 [details] release, v3 https://lists.freedesktop.org/archives/mesa-dev/2017-October/171348.html Reminder: drm-next or drm-next-kmod users may want to build with CFLAGS += -D__DRM_NEXT__ set in either make.conf or Makefile.local. It'd disable some workarounds maintainer added to keep the port working against old DRM kernel code. For one, using EGL with DRI3 can improve performance.
(In reply to Jan Beich from comment #23) Maybe make a port option that adds -D__DRM_NEXT__?
(In reply to Greg V from comment #24) > Maybe make a port option that adds -D__DRM_NEXT__? Why not make a run-time check for whatever functionality is missing or bug present instead? > using EGL with DRI3 can improve performance. Looking at the port's patches now, I can see, that EGL can be triggered without recompiling simply by adding LIBGL_DRI3_ENABLE to the environment...
(In reply to Mikhail T. from comment #25) I'm a bit confused here with what y'all are talking about. DRI3 is the latest X direct rendering protocol. It still works with GLX clients. I have LIBGL_DRI3_ENABLE set, it works. EGL is the window-system-independent protocol for getting a GL context. It's used by Wayland compositors, Android, demos like kmscube… Is it somehow also usable with DRI3 X clients? And disabling the workarounds should boost performance of *that*?
The proposed patch (v3) seems to work fine on my machine -- running the "drm-next" branch of FreeBSD-12 with an Intel's video card.
17.2.2 landed, without mentioning this bug o_0 https://github.com/freebsd/freebsd-ports/commit/6b976bd6fd2a46321cabe1d1b55c90ea4ec282ee
(In reply to Greg V from comment #28) That's r451657 in svn. Does it resolve the issue adequately?
(In reply to Conrad Meyer from comment #29) Well, yeah, it does upgrade Mesa to 17.2.2 :) I'm just surprised that it's a slightly different patch than https://bugs.freebsd.org/bugzilla/attachment.cgi?id=186873&action=diff and from a different committer…
See bug 219247 comment 8. Let's not speculate why x11@ folks prefer to collaborate outside of public eye. There's not much point in keeping this bug open. files/patch-src_egl_Makefile.in appears to be no longer required. NEON detection can be fixed in a better way now that we have AT_HWCAP support on -CURRENT.