mesa-libGL performance bug still exists for fedora 37? #180
Comments
nuitlejour
changed the title
|
Hello, Thanks for reporting. The thing is that the mesa provided by Fedora repos doesn't come compiled with d3d12, so we need to compile it, package it and make it available. It is in our roadmap and I'll tell you when it is ready. Regards, |
|
The latest 22.2.3 is faster than 21.3.1 but in our tests is slower than 21.2.3. But we will update to this version because it provides OpenGL 4 and video decoding (although we have never been able to make it work) |
|
If I understand the challenge correctly, then this is all about Is there a bug report / issue ticket against Fedora that requests that they build and package The expectation would be that FWIW, https://koji.fedoraproject.org/koji/rpminfo?rpmID=33718767 for Fedora 38 does not package D3D12 either (via https://src.fedoraproject.org/rpms/mesa) Additional comments here suggest that even if Fedora did package Is there a bug report / issue ticket against Mesa for this? |
|
Just noticed https://src.fedoraproject.org/rpms/mesa/pull-request/16, so someone made some attempt, but that ended up nowhere. |
|
Just also found https://bugzilla.redhat.com/show_bug.cgi?id=2115560 So, fundamentally, and as of today, Fedora is missing out on a package for the Microsoft DirectX Headers at https://github.com/microsoft/DirectX-Headers (that's what the above Bugzilla review request is about). Once those headers are packaged within Fedora, the mesa build could be conveniently extended such as below - is my understanding of this correct? Note that this patch is wildy hacked up, with a local install of the DirectX headers, and off rawhide, but F37 should be the same and should install fine with diff --git a/mesa.spec b/mesa.spec
index 1a16056..2f02142 100644
--- a/mesa.spec
+++ b/mesa.spec
@@ -13,6 +13,7 @@
%ifarch %{ix86} x86_64
%global with_crocus 1
+%global with_d3d12 1
%global with_i915 1
%global with_iris 1
%global with_xa 1
@@ -136,6 +137,9 @@ BuildRequires: glslang
%if 0%{?with_vulkan_hw}
BuildRequires: pkgconfig(vulkan)
%endif
+%if 0%{?with_d3d12}
+#BuildRequires: pkgconfig(DirectX-Headers) >= 1.608.2
+%endif
%description
%{summary}.
@@ -345,7 +349,7 @@ export RUSTFLAGS="%build_rustflags"
-Ddri3=enabled \
-Dosmesa=true \
%if 0%{?with_hardware}
- -Dgallium-drivers=swrast,virgl,nouveau%{?with_r300:,r300}%{?with_crocus:,crocus}%{?with_i915:,i915}%{?with_iris:,iris}%{?with_vmware:,svga}%{?with_radeonsi:,radeonsi}%{?with_r600:,r600}%{?with_freedreno:,freedreno}%{?with_etnaviv:,etnaviv}%{?with_tegra:,tegra}%{?with_vc4:,vc4}%{?with_v3d:,v3d}%{?with_kmsro:,kmsro}%{?with_lima:,lima}%{?with_panfrost:,panfrost}%{?with_vulkan_hw:,zink} \
+ -Dgallium-drivers=swrast,virgl,nouveau%{?with_r300:,r300}%{?with_crocus:,crocus}%{?with_i915:,i915}%{?with_iris:,iris}%{?with_vmware:,svga}%{?with_radeonsi:,radeonsi}%{?with_r600:,r600}%{?with_freedreno:,freedreno}%{?with_etnaviv:,etnaviv}%{?with_tegra:,tegra}%{?with_vc4:,vc4}%{?with_v3d:,v3d}%{?with_kmsro:,kmsro}%{?with_lima:,lima}%{?with_panfrost:,panfrost}%{?with_vulkan_hw:,zink}%{?with_d3d12:,d3d12} \
%else
-Dgallium-drivers=swrast,virgl \
%endif
@@ -369,6 +373,11 @@ export RUSTFLAGS="%build_rustflags"
-Degl=enabled \
-Dglvnd=true \
-Dmicrosoft-clc=disabled \
+%if 0%{?with_va}
+%if 0%{?with_d3d12}
+ -Dgallium-d3d12-video=enabled \
+%endif
+%endif
-Dllvm=enabled \
-Dshared-llvm=enabled \
-Dvalgrind=%{?with_valgrind:enabled}%{!?with_valgrind:disabled} \
@@ -503,6 +512,7 @@ popd
%endif
%ifarch %{ix86} x86_64
%{_libdir}/dri/crocus_dri.so
+%{_libdir}/dri/d3d12_dri.so
%{_libdir}/dri/i915_dri.so
%{_libdir}/dri/iris_dri.so
%endif
@@ -584,6 +594,9 @@ popd
%if 0%{?with_radeonsi}
%{_libdir}/dri/radeonsi_drv_video.so
%endif
+%if 0%{?with_d3d12}
+%{_libdir}/dri/d3d12_drv_video.so
+%endif
%{_libdir}/dri/virtio_gpu_drv_video.so
%endif
@@ -599,6 +612,9 @@ popd
%if 0%{?with_radeonsi}
%{_libdir}/vdpau/libvdpau_radeonsi.so.1*
%endif
+%if 0%{?with_d3d12}
+%{_libdir}/vdpau/libvdpau_d3d12.so.1*
+%endif
%{_libdir}/vdpau/libvdpau_virtio_gpu.so.1*
%endif |
|
Hello, No problem. We will upgrade the mesa version for Fedora Remix this week. Regards, |
|
Fedora project doesn't officially support WSL and we don't want to enter in this discussion to try to push it upstream. If they and RHEL don't have this support is their desision. We compile mesa with WSL support and upload the resulting packages to our repos then lock the version to avoid the user download the upstream one. |
|
Slightly off-topic WRT Fedora and WSL: As far as I remember the story "back then", the Fedora organization really wanted to deliver Fedora Linux onto WSL - but Microsoft then came up with some contractual constraints (liability?) that Fedora did not want to enter into. From a technical point of view, IMHO, Fedora would be happy to accept changes to further enable Fedora Linux on WSLg; it's just that they don't want to get into a specific contractual situation where they make a formal offer of a spin, i.e. literally "Fedora Linux - WSL edition", off the Microsoft Store. |
|
This is one part of the story. The other is about Redhat and their position about WSL. Without trying to enter in polemics you can notice that Redhat Enterprise Linux doesn't have a WSL version nor CentOS. A patch in Fedora will eventually fall to RHEL. As you said you cannot find any official build even outside the Store which is in theory the legal problem. |
|
Hello, We upgraded the mesa drivers. The performance hit is still there, but now you'll have support for OpenGL 4. It also comes with the video acceleration enabled that I personally haven't been able to use. Maybe it is my hardware. We'll soon test the video acceleration and publish a blog post. Run Here GlxGears before and after the upgrade:
|
|
Many thanks for the refresh of Mesa! FWIW, I have done some terribly non-scientific test of a fully updated, very fresh Fedora 37, no tweaks, on a Dell Inspiron 7610 laptop (Tiger Lake, Intel XE + RTX3060, 64 GB) [***]:
Functionally, IDEs such as IntelliJ and Visual Studio Code seem to scroll text fast enough. I even get Firefox to render a Youtube 4K video on the 4K screen, fullscreen (no video acceleration) - this is a bit jittery, but after all this is all through WSLg. As a final test, the latest version of Microsoft Edge "dev" (112) on Fedora quite nicely renders a 4K action scene from Avengers (https://www.youtube.com/watch?v=rrGMENN1iaY) at 4K on the 4K screen with very very tolerable quality - amazing. [***]
There might be room for improvement by tweaking things "somewhere", still, but for me right now this Very Much Good Enough. |
|
I think I really need to qualify my comments above: Fedora 37 does use llvmpipe. Not D3D12. I just installed "Ubuntu (Preview)" from the Microsoft Store - and what I see there is totally horrible: Extremely slow performance on glxgears, jitter, functional defects, Microsoft Edge does not start etc - and that with d3d12 (according to glxinfo -B) This suggests that my d3d12 setup on Fedora is broken right now - and I am not too unhappy that, given what I see on Ubuntu, right now ... |
|
I just updated both the Intel and Nvidia drivers. Fedora still is on llvmpipe, but with better performance - glxgears slightly down to ~875 FPS Ubuntu (23.04, effectively) still has d3d12, but now mostly working, with a many visual artefacts. glxgears is around 60 FPS. With Truth to be told - on my system, I am not sure why I should be using d3d12. Neither Ubuntu nor Fedora appear to work well with it. Funky. |
|
OK if you have the latest mesa and d3d12 works on Ubuntu but no on Fedora probably you have the non-wsl mesa packages. Run As you said you can always disable the acceleration with the environment variable. The theory is that although you see a drop in FPS in glxgears which is a very simple model, you should gain performance using the GPU with complex models, like for example render a scene in Blender. |
|
I tried Perhaps the Right now I am reasonably sure that update/upgrade ran without errors; the state of my system is and (note that I do have Mesa 23.0.0 RPMs built locally inside F37/WSL with and On Ubuntu (running in parallel) I get and, really, it takes half an eternity (500 ms?) for that output to show (with llvmpipe its instantaneous) FWIW, there is some general interoperability going on - I can run compute on the NVidia card from WSL2, so generally it is accessible (keeping in mind to always fix the out-of-whack CUDA setup via https://forums.developer.nvidia.com/t/wsl2-libcuda-so-and-libcuda-so-1-should-be-symlink/236301) In an ideal world, for accelerate graphics I'd be able to choose between
I have no idea how feasible this ideal world is with my hardware and (Windows, Linux) drivers; I wouldn't invest too much time into that, as CUDA is my main concern - and that works. For me, accelerated graphics inside WSL2 would only be an interesting thing to have. |
|
You can choose Nvidia card by using:
I don't understand why is not picking the d3d12. Are you inside a desktop environment or something like that? |
|
Unfortunately,
... but according to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10710/diffs#a7d30d7e3ed27f77d78e6873c484281764144c8c_77_77 the name is Insight gained from that (i.e. Nvidia turned on for Ubuntu):
So 👍 on that :) |
|
Good at least advanced a bit. Still don't know why in Fedora is not working |
|
I am quite at a loss to understand why things work on Ubuntu, but not on Fedora. The existing Fedora is, mostly, a pristine installation of your fantastic Fedora Remix, with some adjustments (IIRC):
My experiments above are based on starting Windows Terminal, logging into the Fedora console, and then immediately running So ... I created a fresh installation of Fedora Remix (uninstall / unregister -> install) and now
This is Windows 11 22H2. All the packages and drivers are present as expected. I added But here is something really surprising:
IOW, there is something wrong with the installation of the Intel drivers on Fedora that has the effect that d3d12 appears to be broken. Forcing the Nvidia driver then works, i.e.
This leaves the question: What's wrong with the Intel driver installation on Fedora that it does not want to work through d3d12? I took a look at Ubuntu: Fedora: ... but it is not really obvious why I tried And
And, yes, that's the exact same thing from https://www.thrysoee.dk/editline/ Resolution / hack: And that finally, on Fedora 37 pristine + the hack, yields The root cause for all of that is that IOW, Intel most likely built their Linux driver bundle on Ubuntu. And the SONAMEs there are just plain incompatible with Fedora. |
|
TL;DR: To marry the Mesa d3d12 driver with a Windows Intel driver for WSLg, the only solution on Fedora is |
|
FWIW, I was complaining about the large amount of visual artefacts on the Intel driver in Ubuntu - well even with their WSL Ubuntu Preview (23.04), they ship Mesa 22.2.5 It would seem as if a thing or two were fixed between Mesa 22.2.5 und 22.3.6, because I currently don't see these virtual artefacts on Fedora. Video acceleration does not work on either distro - Ubuntu apparently doesn't ship that (at all), and on Fedora init fails (for Intel only) with |
|
Wow you did a huge investigation on making it work. I was thinking about the version difference between Ubuntu and Fedora, but I never though anything about not loading a library. We are working on video acceleration. Because Fedora Team removed the video codecs from Fedora 37. And not only from mesa but from others like ffmpeg. So the user need to use another repo and install the full version of these programs. We will publish a blog post with all the steps. And I'll try to incorporate your findings into the image. So, other users can work with Intel cards Best Regards |
|
Just created a bug on WSLg for that at microsoft/wslg#996 |
|
The hardware codec video acceleration challenge in general on Fedora is actually relatively tame, IMHO: barely anyone is affected because only few codecs on very few real hardware is affected (effectively AMD only) and the solution is https://rpmfusion.org/Howto/Multimedia?highlight=%28%5CbCategoryHowto%5Cb%29 (via rpmfusion-infra/fedy#110) So, for WSLg, I don't see hardware video acceleration as much a problem (although what Nvidia manage to accomplish is quite astounding, to be honest) Just my two cents. |
|
With respect to performance, I took inspiration from https://devblogs.microsoft.com/commandline/wslg-architecture/#hardware-accelerated-opengl and just ran those tests locally on the "fixed" Fedora 37. TL;DR: The FPS on my system went 3 (llvmpipe) -> 30 (Intel) -> 103 (Nvidia). Whoops. Apparently the performance "problem" with WSLg is all around the overhead transitioning between Mesa on the Linux side and execution on the real hardware: The more complex the individual batch is that can be executed on the hardware, the better the results are from the benchmark. The "Piano" test in this benchmark exposes this, as does the "Voloplosion". IOW, |
|
hello, there |
|
Connection refused is a networking (infrastructure) issue - nothing this project here can change. That having been said, retry in the curl and explicit timeouts in the update script might make that more resilient (am unable to locate the current authoritative source for that script though) |
|
OK it is a good point. Let's investigate a bit to see if we can put a loop with five retries or something similar. Thanks for the suggestion |
|
I have added url rule to my host file as follows, it works now: |
|
Just wanted to leave a note on the GpuTest benchmark for my specific laptop, on Windows 11, in a specific display configuration... 40 fps native vs (still) 100+ fps through WSLg (through Ubuntu 23.04 Preview + mesa git) Funky. |
Describe the bug
The latest mesa-libGL-devel (version 22.2.3-1.fc37) is filtered out by fedora remix.
It does say in the README.md that:
'Upgraded Mesa to 21.2.3, the latest version 21.3.1 provided by upstream Fedora 35 has a serious performance issue with GPU and WSLg'
Is it still an issue for the latest mesa-libGL-devel (version 22.2.3-1.fc37) ?
To Reproduce
dnf install mesa-libGL-devel, and returns:
package mesa-libGL-22.2.3-1.fc37.x86_64 is filtered out by exclude filtering
The text was updated successfully, but these errors were encountered: