Created attachment 244752 [details] update to 23.1.7 The attached patch updates mesa to 23.1.7. Only mesa-libs and mesa-dri have been built. Tested with Xorg 21.1.8 and drm-fbsd12.0-kmod (i915kms) on Haswell.
Please provide build logs for all mesa ports. If a patch isn't needed anymore you should git rm files/patch-XXX
Created attachment 244817 [details] update to 23.1.7 (v2)
@comment #1 > If a patch isn't needed anymore you should git rm files/patch-XXX My ports tree is not managed with git. > Please provide build logs for all mesa ports. Sorry, that is out of scope for me :-/ I cannot build AMD related ports since I disabled this support in my locally built packages of libdrm and llvm (eg., this means I have to replace r300 with crocus as gallium driver when building mesa-libs). - mesa-dri builds successfully without VULKAN SWRAST and without all AMD. Patches for libosmesa and mesa-gallium-xa updated: - dri-drivers removed - xlib-lease=disabled added ->build successfully now Patches for mesa-gallium-va, mesa-gallium-vdpau updated: - dri-drivers removed - might need xlib-lease=disabled -> unable to build because of missing AMD support in required ports Patch for lang/clover updated: - dri-drivers removed - xlib-lease=disabled added -> unable to build because of missing AMD support in required ports
With AMD support enabled in graphics/mesa-dri, build fails: samu: job failed with status 1: cc -Isrc/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a.p -Isrc/gallium/winsys/amdgpu/drm -I../src/gallium/winsys/amdgpu/drm -Isrc/amd -I../src/amd -I../src/gallium/include -Isrc/gallium/auxiliary -I../src/gallium/auxiliary -Iinclude -I../include -Isrc -I../src -Isrc/amd/common -I../src/amd/common -Isrc/amd/llvm -I../src/amd/llvm -I/usr/local/include -I/usr/local/include/libdrm -fvisibility=hidden -fno-color-diagnostics -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 '-DPACKAGE_VERSION="23.1.7"' '-DPACKAGE_BUGREPORT="https://gitlab.freedesktop.org/mesa/mesa/-/issues"' -DHAVE_OPENGL=1 -DHAVE_OPENGL_ES_1=0 -DHAVE_OPENGL_ES_2=0 -DHAVE_SWRAST -DHAVE_ZINK -DHAVE_R300 -DHAVE_R600 -DHAVE_RADEONSI -DHAVE_CROCUS -DHAVE_I915 -DHAVE_IRIS -DHAVE_SVGA -DVIDEO_CODEC_VC1DEC=0 -DVIDEO_CODEC_H264DEC=0 -DVIDEO_CODEC_H264ENC=0 -DVIDEO_CODEC_H265DEC=0 -DVIDEO_CODEC_H265ENC=0 -DHAVE_X11_PLATFORM -DHAVE_WAYLAND_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DHAVE_DRM_PLATFORM -DHAVE_XCB_PLATFORM -DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_DRM -DALLOW_KCMP -DETIME=ETIMEDOUT -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL -DHAVE___BUILTIN_UNREACHABLE -DHAVE___BUILTIN_TYPES_COMPATIBLE_P -DHAVE_FUNC_ATTRIBUTE_CONST -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC -DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL -DHAVE_FUNC_ATTRIBUTE_ALIAS -DHAVE_FUNC_ATTRIBUTE_NORETURN -DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_UINT128 -DHAVE_REALLOCARRAY -DHAVE_FMEMOPEN -D_GNU_SOURCE -DUSE_SSE41 -DUSE_GCC_ATOMIC_BUILTINS -DUSE_X86_64_ASM -DHAS_SCHED_H -DHAS_SCHED_GETAFFINITY -DHAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H -DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_SYS_SHM_H -DHAVE_CET_H -DHAVE_PTHREAD_NP_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_FLOCK -DHAVE_STRTOK_R -DHAVE_GETRANDOM -DHAVE_QSORT_S -DHAVE_POSIX_FALLOCATE -DHAVE_GNU_QSORT_R -DHAVE_STRUCT_TIMESPEC -DHAVE_POSIX_MEMALIGN -DHAVE_DIRENT_D_TYPE -DHAVE_STRTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DSUPPORT_INTEL_INTEGRATED_GPUS -DHAVE_ZLIB -DHAVE_ZSTD -DHAVE_COMPRESSION -DHAVE_PTHREAD -DHAVE_LIBDRM -DLLVM_AVAILABLE '-DMESA_LLVM_VERSION_STRING="16.0.6"' -DLLVM_IS_SHARED=1 -DDRAW_LLVM_AVAILABLE -DUSE_LIBELF -DMESA_EXECMEM -DHAVE_LIBUNWIND -DWL_HIDE_DEPRECATED -DHAVE_DRI -DHAVE_DRI2 -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS -DHAVE_DRISW_KMS -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=empty-body -Werror=incompatible-pointer-types -Werror=int-conversion -Wimplicit-fallthrough -Wmisleading-indentation -Wno-missing-field-initializers -fno-math-errno -fno-trapping-math -Qunused-arguments -fno-common -Wno-microsoft-enum-value -Wno-unused-function -Werror=format -Wformat-security -ffunction-sections -fdata-sections -Wno-unused-variable -Wno-unused-but-set-variable -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -fPIC -pthread -isystem/usr/local/llvm16/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -MD -MQ src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a.p/amdgpu_bo.c.o -MF src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a.p/amdgpu_bo.c.o.d -o src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a.p/amdgpu_bo.c.o -c ../src/gallium/winsys/amdgpu/drm/amdgpu_bo.c ../src/gallium/winsys/amdgpu/drm/amdgpu_bo.c:1648:34: error: use of undeclared identifier 'u64' r = ioctl(whandle->handle, DMA_BUF_SET_NAME_B, (uint64_t)(uintptr_t)dmabufname); ^ ../include/drm-uapi/dma-buf.h:191:50: note: expanded from macro 'DMA_BUF_SET_NAME_B' #define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64) ^ 1 error generated.
Created attachment 244859 [details] v3 Logs: https://people.freebsd.org/~vishwin/mesa-23.1.7/ Don't have AMD hardware to test with, but will report back with my Intel hardware. Definitely needs more testing regardless. Makefiles and patches probably need more cleaning. (In reply to gnikl from comment #3) Next time you submit patches, please use something that also outputs all file creations and deletions.
Building locally, will try to find time to test on different machines this weekend. Thanks both.
Can you add -Dvideo-codecs="vc1dec,h264dec,h264enc,h265dec,h265enc" to graphics/mesa-dri for Vulkan Video on Intel GPUs? It's a new feature in Mesa 23.0: see bug 272575, ports aada4209a3b0 and https://gitlab.freedesktop.org/mesa/mesa/-/commit/c90e5ddc710a for details.
@comment #5 > Next time you submit patches, please use something that also outputs all file creations and deletions. Thank you for stepping in and sorry for the hassle! The first patch had the deletions, in the second patch I omitted them because of the "git rm" remark. In retrospect it would have been better to had the removals in a separate patch. @comment #5 > ../include/drm-uapi/dma-buf.h:191:50: note: expanded from macro 'DMA_BUF_SET_NAME_B' > #define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64) AFAICT, that is the "old" dma-buf.h. The version in 23.1.7 uses __u64 here.
(In reply to Jan Beich from comment #7) Oops, Vulkan Video on AMD GPUs is also affected as mesa-gallium-va (passes -Dvideo-codecs) is a separate package unlike in mesa-devel.
(In reply to Jan Beich from comment #7) There is also d3d12 to be possibly added somewhere, hence "more cleaning". (In reply to gnikl from comment #8) > AFAICT, that is the "old" dma-buf.h. The version in 23.1.7 uses __u64 here. Yes, I realised that the dma-buf.h patch just appended itself to the correct one thus creating the clashing. Got a bit trigger happy before I finished figuring out which leftover patches needed to go.
(In reply to Charlie Li from comment #10) AFAIK, D3D12 in Mesa requires Hyper-V interop and used by WSLg (e.g., Weston on Windows). It's not yet supported on FreeBSD unlike Vulkan Video.
It doesn't work on amdgpu : https://dpaste.com/FVBCVTTK8 I have no time to debug/bisect now.
FWIW, updating Mesa is a good opportunity to bump LLVM used. Given how rarely it happens maybe jump straight to devel/llvm17. (In reply to Emmanuel Vadot from comment #12) Before bisecting maybe try mesa-devel. If it works fine then there's something wrong with mesa-dri port... or specific upstream release.
(In reply to Jan Beich from comment #13) The entire 23.1 branch does not build under LLVM 17 because a preprocessor guard for the Legacy Pass Manager C bindings was not properly placed. The commit fixing such is only present in 23.2 and later.
Created attachment 245135 [details] v4 Pulls in commit from 23.2/main to fix build with LLVM 17 and other recent versions, as the Legacy Pass Manager was already deprecated but only removed in 17.
Hello, thank you for your patch! I can confirm with an AMD Radeon RX 6700 XT that everything continues to working for me. The only thing is that, i do see the message: amdgpu: os_same_file_description couldn't determine if two DRM fds reference the same file description. If they do, bad things may happen! During usage of mpv and glxinfo | grep OpenGL.
I've started a build, will test on my different hardware soon-ish.
v4 still lacks Vulkan Video support in mesa-dri (libvulkan_*.so) as noted in comment 7. May be important on recent Intel GPUs (e.g., some Alder Lake, Arc Alchemist) due to unmaintained and out-of-date multimedia/libva-intel-media-driver.
(In reply to Jan Beich from comment #18) Yes I will add this, I'm updating the patch to have a few other PR patches in it anyway.
So wayland (well, eGL to be exact) is still broken on amd hardware (at least). It's not with mesa-devel. This could be due on how we compile the different parts of mesa independently.
Managed to make it work, will need some more test on different hardware and still need to see how to add vulkan video drivers (and for that I need to rebuild some ports like ffmpeg).
So vulkan video doesn't work on AMD (A lot of artifacts when decoding on my RX550). On Intel it result in this : MESA-INTEL: warning: ../src/intel/vulkan/anv_formats.c:767: FINISHME: support more multi-planar formats with DRM modifiers [ffmpeg/video] h264: Device does not support the VK_KHR_video_decode_queue extension! On my whiskeylake laptop, same thing with mesa-devel. So I'll just leave the video stuff for another update.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=29d855b6f775be3f43aa5fb4b45c88ca9711dfd3 commit 29d855b6f775be3f43aa5fb4b45c88ca9711dfd3 Author: gnikl <gnikl@justmail.de> AuthorDate: 2023-09-14 23:16:00 +0000 Commit: Emmanuel Vadot <manu@FreeBSD.org> CommitDate: 2023-11-21 15:17:28 +0000 graphics/mesa: update to 23.1.8 While here: - Remove some unneeded dep in gallium-vdpau - Disable libelf from devel/elfutils (we will fallback on base libelf), PR 273803 - Always disable libunwind, if you want stacktrace you will need to compile from upstream PR: 250306 - enable vulkan haswell driver Co-authored-by: manu, vishwin PR: 273703, 273803, 250306 graphics/libosmesa/Makefile | 12 +- graphics/mesa-dri/Makefile | 22 ++- graphics/mesa-dri/Makefile.common | 29 ++- graphics/mesa-dri/distinfo | 10 +- .../files/patch-include_drm-uapi_dma-buf.h (gone) | 198 --------------------- ...h-src_gallium_include_pipe_p__compiler.h (gone) | 11 -- .../mesa-dri/files/patch-src_util_macros.h (gone) | 11 -- graphics/mesa-dri/files/patch-src_util_u__memory.h | 18 +- .../patch-src_vulkan_wsi_wsi__common__drm.c (gone) | 61 ------- graphics/mesa-dri/files/patch-wayland-1.22 (gone) | 44 ----- graphics/mesa-dri/pkg-plist | 2 + graphics/mesa-gallium-va/Makefile | 9 +- graphics/mesa-gallium-vdpau/Makefile | 13 +- graphics/mesa-gallium-vdpau/pkg-plist | 4 - graphics/mesa-gallium-xa/Makefile | 13 +- graphics/mesa-libs/Makefile | 6 +- lang/clover/Makefile | 16 +- 17 files changed, 90 insertions(+), 389 deletions(-)
(In reply to Emmanuel Vadot from comment #22) Did you set ANV_VIDEO_DECODE=1 on Intel and RADV_PERFTEST=video_decode on AMD GPUs via environ(7) like bug 272575 suggested? I've been dogfooding --hwdec=vulkan for >2 months on Intel Skylake with mesa-devel and drm-515-kmod. If you see artifacts (e.g., green video in my case) try reverting ports e14404ac73e7 or try 5.15-lts branch mentioned in bug 274770.
(In reply to Jan Beich from comment #24) I did for AMD, maybe I forgot for Intel. Will try again later but again this will be addressed in a future mesa update.
(In reply to Jan Beich from comment #24) I indeed did forgot about ANV_VIDEO_DECODE=1 when testing on Intel, it works fine with mesa-devel but couldn't managed to make it work with mesa-dri, likely because how we build them. With subpackage being close I'll just wait for it and rework the mesa ports then.
(In reply to Emmanuel Vadot from comment #26) *Sigh* Talking via patches is far easier than using words. Vulkan Video in mesa-dri 23.1.8 works fine for me with the following patch (what comment 7 suggested): diff --git a/graphics/mesa-dri/Makefile b/graphics/mesa-dri/Makefile index e309b1adf75f..deaafb456495 100644 --- a/graphics/mesa-dri/Makefile +++ b/graphics/mesa-dri/Makefile @@ -1,6 +1,6 @@ PORTNAME= mesa-dri PORTVERSION= ${MESAVERSION} -PORTREVISION= 1 +PORTREVISION= 2 CATEGORIES= graphics COMMENT= OpenGL hardware acceleration drivers for DRI2+ @@ -73,6 +73,9 @@ MESON_ARGS+= -Dgallium-drivers="${GALLIUM_DRIVERS:ts,:tl}" \ -Dvulkan-drivers="${VULKAN_DRIVERS:ts,:tl}" \ -Dplatforms="${MESA_PLATFORMS:ts,:tl}" +# Vulkan Video +MESON_ARGS+= -Dvideo-codecs="vc1dec,h264dec,h264enc,h265dec,h265enc" + # Disable some options MESON_ARGS+= -Dandroid-libbacktrace=disabled \ -Dgallium-xa=disabled \