iris is a Gallium-based OpenGL driver for Intel Broadwell and newer. It was introduced in Mesa 19.1 and became default in Mesa 20.0. See also https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2895 I need iris to drop emulators/rpcs3/pkg-message and emulators/yuzu/pkg-message.
Yeah I forgot to add the iris driver to the list even if I did build and test it from git .. Thanks for noticing, will send a patch tomorow.
A commit references this bug: Author: manu Date: Tue Oct 13 11:53:51 UTC 2020 New revision: 552236 URL: https://svnweb.freebsd.org/changeset/ports/552236 Log: graphics/mesa*: Add Iris Gallium driver and libunwind for more arch Iris is the prefered gallium driver for Intel Gen8 to Gen11, add it to the build. [1] Add libunwind support for more arch. [2] PR: 250307 [1], 250305 [2] Submitted by: jbeich [2] Reported by: jbeich [1] Reviewed by: zeising Changes: head/graphics/libosmesa/Makefile head/graphics/mesa-dri/Makefile head/graphics/mesa-dri/Makefile.common head/graphics/mesa-dri/pkg-plist head/graphics/mesa-gallium-va/Makefile head/graphics/mesa-gallium-vdpau/Makefile head/graphics/mesa-gallium-xa/Makefile head/graphics/mesa-libs/Makefile head/lang/clover/Makefile
Any clue why mesa-dri doesn't use iris by default? $ pkg install mesa-dri glx-utils $ pkg info -l mesa-dri | fgrep iris /usr/local/lib/dri/iris_dri.so $ LIBGL_DEBUG=verbose glxgears 2>&1 | fgrep lib/dri libGL: MESA-LOADER: dlopen(/usr/local/lib/dri/i965_dri.so) ^C $ pkg install mesa-devel $ LIBGL_DEBUG=verbose glxgears 2>&1 | fgrep lib/dri libGL: MESA-LOADER: dlopen(/usr/local/lib/dri-devel/iris_dri.so) ^C
(In reply to Jan Beich from comment #3) The version in the non-devel port is quite old, I'm pretty sure it doesn't prefer iris, that was done relatively recently.
(In reply to Greg V from comment #4) I have -DPREFER_IRIS in mesa-dri build log, so my GPU (0x1912) shouldn't be using i965 by default.
For example, i965 compat profile doesn't have GL_ARB_direct_state_access required by yuzu. To demonstrate a glitch it causes try the following: $ pkg install yuzu-qt5 mesa-dri $ fetch https://github.com/FlagBrew/2048/releases/download/1.0.0-1/2048.nro $ export HOME=/tmp # use default config e.g., homebrew needs ASYNC disabled $ yuzu 2048.nro <Game has launched but screen remains black> $ MESA_LOADER_DRIVER_OVERRIDE=iris yuzu 2048.nro <Game board is rendered properly> $ MESA_GL_VERSION_OVERRIDE=4.6COMPAT yuzu 2048.nro <Game board is rendered properly> https://gitlab.freedesktop.org/mesa/mesa/-/blob/mesa-20.2.0/src/mesa/drivers/dri/i965/intel_screen.c#L2440
(In reply to Jan Beich from comment #6) It seems loader.c must be compiled with "-DPREFER_IRIS". Applying the following patch and rebuilding/reinstalling graphics/mesa-libs fixed the problem for me. --- src/loader/meson.build.orig 2020-09-28 22:52:12 UTC +++ src/loader/meson.build @@ -41,7 +41,7 @@ loader_c_args = [ '-DDEFAULT_DRIVER_DIR="@0@"'.format(dri_search_path), ] -if with_gallium_iris and get_option('prefer-iris') +if get_option('prefer-iris') loader_c_args += ['-DPREFER_IRIS'] endif
It's little off-topic but I was not able to use SNA with iris. It always failed with "(WW) intel(0): Detected unsupported/dysfunctional hardware, disabling acceleration." in the log file. I did some debugging and found it always failed at test_has_execbuffer2() function although we've been supporting DRM_IOCTL_I915_GEM_EXECBUFFER2 ioctl for many years. IIRC, it was supported even in drm2 days. As a work-around, commenting out the test function let me enable SNA successfully, i.e., Index: x11-drivers/xf86-video-intel/files/patch-src_sna_kgem.c =================================================================== --- x11-drivers/xf86-video-intel/files/patch-src_sna_kgem.c (nonexistent) +++ x11-drivers/xf86-video-intel/files/patch-src_sna_kgem.c (working copy) @@ -0,0 +1,29 @@ +--- src/sna/kgem.c.orig 2020-05-15 16:56:58 UTC ++++ src/sna/kgem.c +@@ -1186,6 +1186,7 @@ static int gem_param(struct kgem *kgem, int name) + return v; + } + ++#ifndef __FreeBSD__ + static bool test_has_execbuffer2(struct kgem *kgem) + { + struct drm_i915_gem_execbuffer2 execbuf; +@@ -1197,6 +1198,7 @@ static bool test_has_execbuffer2(struct kgem *kgem) + DRM_IOCTL_I915_GEM_EXECBUFFER2, + &execbuf) == -EFAULT; + } ++#endif + + static bool test_has_no_reloc(struct kgem *kgem) + { +@@ -1252,8 +1254,10 @@ static bool is_hw_supported(struct kgem *kgem, + if (DBG_NO_HW) + return false; + ++#ifndef __FreeBSD__ + if (!test_has_execbuffer2(kgem)) + return false; ++#endif + + if (kgem->gen == (unsigned)-1) /* unknown chipset, assume future gen */ + return kgem->has_blt; In fact, I've been using this for few weeks now without a problem. My guess is the ioctl wrapper do_ioctl() isn't working for our ioctl handler.
We'll have to look at the issue with iris not being used by default. I find that the patch you suggested is a bit strange, with_gallium_iris should be defined, and adding this patch means that the loader will try to use iris even when it's disabled, which maybe causes issues (I haven't looked). Can you break out the SNA issue to a separate bug?
(In reply to Niclas Zeising from comment #9) > with_gallium_iris should be defined, and adding this patch means > that the loader will try to use iris even when it's disabled loader.c is part of libGL.so, libEGL.so and libgbm.so from mesa-libs which is built with -Dgallium-drivers="", so with_gallium_iris is false. Other downstreams (Alpine, Arch, Fedora, Debian, Void) split libraries into a separate package after building with all drivers enabled (for a given architecture), so with_gallium_iris is true.
A commit references this bug: Author: manu Date: Thu Dec 3 20:55:35 UTC 2020 New revision: 556929 URL: https://svnweb.freebsd.org/changeset/ports/556929 Log: mesa-*: Update to 20.2.3 - Fix mesa-gallium-va and mesa-gallium-vdpau for X11 usage - Add a patch so iris will be prefered for compatible intel GPUs (>=broadwell) PR: 250307 250325 Changes: head/graphics/libosmesa/Makefile head/graphics/mesa-dri/Makefile head/graphics/mesa-dri/Makefile.common head/graphics/mesa-dri/distinfo head/graphics/mesa-dri/files/patch-src_loader_meson.build head/graphics/mesa-gallium-va/Makefile head/graphics/mesa-gallium-va/pkg-plist head/graphics/mesa-gallium-vdpau/Makefile head/graphics/mesa-gallium-vdpau/pkg-plist head/graphics/mesa-gallium-xa/Makefile head/graphics/mesa-libs/Makefile head/lang/clover/Makefile
Fixed in r556929
(In reply to Jung-uk Kim from comment #8) > (WW) intel(0): Detected unsupported/dysfunctional hardware, disabling acceleration. I couldn't reproduce on Skylake but my testing was short (dogfooding Sway instead). Did you enable DRI3? DRI2 support in Mesa is poorly tested nowadays. Can you check if applying bug 251588 helps? AIGLX may ignore whatever Mesa prefers. Mixing i965 and iris shouldn't cause issues but who knows, Xorg is a graveyard with legacy features getting in the way like zombies. ;) Can you check if installing graphics/mesa-devel helps? It has TLS (global-dynamic) and GEM export (KCMP_FILE) fixed.
(In reply to Jan Beich from comment #13) > I couldn't reproduce on Skylake but my testing was short (dogfooding Sway > instead). Did you enable DRI3? DRI2 support in Mesa is poorly tested nowadays. Yes, of course. [ 38.023] (**) intel(0): Option "AccelMethod" "SNA" [ 38.023] (**) intel(0): Option "DRI" "3" > Can you check if applying bug 251588 helps? AIGLX may ignore whatever Mesa > prefers. Mixing i965 and iris shouldn't cause issues but who knows, Xorg is a > graveyard with legacy features getting in the way like zombies. ;) Unfortunately, it didn't help. :-( > Can you check if installing graphics/mesa-devel helps? It has TLS (global- > dynamic) and GEM export (KCMP_FILE) fixed. Sorry, the same problem.
mesa-dri/files/patch-src_loader_meson.build to be upstreamed as https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11655