Nothing changed.
1 Like
In my opinion, glxgears is not a good benchmark because “real-world” functions are more complex. It could appear to be performing well while only using software rendering. As far as I know, it just proves that any Mesa driver is in use.
glxgears gives
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor's refresh rate.
301 frames in 5.0 seconds = 60.050 FPS.
[...]
Not that impressive, is it? glxinfo | grep renderer outputs:
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Mesa Intel(R) Graphics (ADL GT2).
You’ll notice the difference when moving windows, minimizing, maximizing and within LibreOffice Draw playing with perspective, rotating objects, changing lights etc. It’s like night and day over here. (Though locked to 60Hz screen refresh rate.)
If it’s locked to the screen refresh rate, I think it means that the compositor is working, otherwise it’s just going foobar and displaying as much as possible, if it can display 1000 fps I assume it should be fine displaying windows from qubes.
It’s not really DM window frames, as far as I can see:
It’s OpenGL modelling.
I don’t know what it measures exactly to be honest 
Looking at the code does not makes thing obvious for me, I’m not skilled enough with LibGL
/** Draw single frame, do SwapBuffers, compute FPS */
static void
draw_frame(Display *dpy, Window win)
{
static int frames = 0;
static double tRot0 = -1.0, tRate0 = -1.0;
double dt, t = current_time();
if (tRot0 < 0.0)
tRot0 = t;
dt = t - tRot0;
tRot0 = t;
if (animate) {
/* advance rotation for next frame */
angle += 70.0 * dt; /* 70 degrees per second */
if (angle > 3600.0)
angle -= 3600.0;
}
draw_gears();
glXSwapBuffers(dpy, win);
frames++;
if (tRate0 < 0.0)
tRate0 = t;
if (t - tRate0 >= 5.0) {
GLfloat seconds = t - tRate0;
GLfloat fps = frames / seconds;
printf("%d frames in %3.1f seconds = %6.3f FPS\n", frames, seconds,
fps);
fflush(stdout);
tRate0 = t;
frames = 0;
}
}
But to come back to DRI – it’s much more than just drawing some edges:
A suggestion on how to proceed:
To enable the “full” hardware capabilities, you need xe/i915 hardware acceleration in X11. It’s hard to say exactly what features are in which driver. For more information, see the original “Merge Acceptance Plan” from the 6.6 kernel here:
https://www.kernel.org/doc/html/v6.6/gpu/rfc/xe.html
Do the following steps:
[1] Load the drivers (or make sure, they are loaded) by
modprobe xe i915
in dom0 terminal.
[2] Check again by
lsmod | grep -e xe -e i915
This should show both modules loaded with some bindings.
[3] Now make sure you load the xe module as the primary driver. It is not always detected. (See e.g. qubes issue 8561 here – marmarek’s final comment: sys-gui-gpu on 13th gen Intel ends in black screen after boot. · Issue #8561 · QubesOS/qubes-issues · GitHub ) It means you need to force probing for this module by pci device id. You can find this id by running lspci
lspci -nn | grep VGA
in the dom0 terminal. It’s the tupel in square brackets. The first id is the vendor id, the second is a device id. You need the second, the graphic device id. Intel lists it on their website as 7d55 for the Ultra 7 155H. The above command should give you the same id.
Now edit /etc/default/grub in the dom0 terminal; add xe.force_probe=7d55 at the end of the line starting with GRUB_CMD_LINUX inside the quotes. Update the grub configuration by issuing
sudo grub2-mkconfig -o $(sudo find /boot -iname "*.cfg")
in dom0 terminal. This essentially tries to update the file it finds as a valid cfg file. You could do this step by step with “more” control:
sudo find /boot -iname "*.cfg"
and then
sudo grub2-mkconfig -o FILENAME_YOU_FOUND_WITH_FULL_PATH
The inclusive command version should be save, as grub2-mkconfig will fail if there is no valid cfg file. Once that’s done, do some sync inside the dom0 terminal (I know, it’s pretty paranoid, but I’ve gotten so used to it – it’s second nature now).
[4] Try rebooting.
[4.1] If startup hangs, you can edit grub by pressing e, edit the kernel line with the typo and save with f10.
[4.2] If not, you are good to go and check inside the dom0 terminal:
lsmod | grep xe
xe should now be the primary module, sometimes as a single bind, sometimes in conjunction with i915. If both xe and i915 drivers are present, xe should be referenced first. Like this:
xe 3526656 0
drm_ttm_helper 16384 1 xe
gpu_sched 65536 1 xe
drm_suballoc_helper 16384 1 xe
drm_gpuvm 45056 1 xe
drm_exec 12288 2 drm_gpuvm,xe
i915 5054464 4
i2c_algo_bit 20480 2 xe,i915
drm_buddy 28672 2 xe,i915
ttm 114688 3 drm_ttm_helper,xe,i915
drm_display_helper 299008 2 xe,i915
cec 98304 3 drm_display_helper,xe,i915
video 81920 2 xe,i915
[5] Check X11 logs in the dom0 terminal, which should contain some DRI loading info messages with iris references:
cat /var/log/Xorg.0.log | grep iris
It should output something like this (with different timestamps):
[30.074] (II) modeset(0): [DRI2] DRI driver: iris
[30.332] (II) AIGLX: Loaded and initialized iris
You should now be able to watch YouTube (embedded) videos even with ambient mode enabled, and LibreOffice applications should render much faster. (Over here they do.)
Same setup, really poor performance. Did try your steps with no improvements (had to do a extra step and blacklist i915 so xe would be used). This is really blocking me to use Qubes as my main os. Currently falling back on my mac or my arch machine for all work.
Even with these changes it goes for llvmpipe… I think the issue might be that Mesa 23… does not have the proper support for meteor lake and I think xe was added in Mesa 24… i915 seems to also fallback to llvmpipe.
Should have noticed this earlier when I wrote my HCL. My bad will check closer next time.
Blacklisting i915 here with NV41/AlderLake caused llvmpipe to be used by xorg as well. There seems to be some overlap in functionality between the two drivers. I think you are ultimately right: it does come down to mesa (version).
The qube can’t have hardware accelerated rendering, so it will always be using llvmpipe inside a qube
I’m talking about dom0. And there things could be different. (And do have an effect.)
Edith adds: It’s even in the FAQs:
Can I run applications, like games, which require 3D support? → Those won’t fly. We do not provide OpenGL virtualization for AppVMs. This is mostly a security decision, as implementing such a feature would most likely introduce a great deal of complexity into the GUI virtualization infrastructure. However, Qubes does allow for the use of accelerated graphics (OpenGL) in Dom0’s Window Manager, so all the fancy desktop effects should still work.
2 Likes
Yes, just so we all on the same page. Was also talking about dom0, have not done anything in a qube yet.
1 Like
NUC 14, kernel-latest and still fscking llvmpipe here. Tried both xe and i915, no luck. That’s very annoying. Hope things would be different on 4.3.
It is sad that “Qubes certified” is typical “Linux certified” as in “does it boot into GUI?”. I expected more attention to the details.
1 Like
There can only be llvmpipe in qubes, I don’t understand what you are checking exactly?
As for VirtIO, discusion if Xen should utilise VirtGL or Wayland has not ended and there is no decision yet.
Lack of dom0 accelerations DRAMATICALLY affects performance. No, it should not be llvmpipe in dom0. You got llvmpipe == libreoffice get unusable. If I only knew I’d never upgrade to Meteor Lake.
2 Likes
I see, but you mentioned nuc 14 and certified hardware, I can only find an Asus nuc 14 with that name and it’s not certified?
Yes, but it has the same chipset and video card as OP’s computer, and same problem. That’s why I am answering in this thread.
1 Like
Even though things are offloaded to dom0 and there is no hardware acceleration in regular app qubes … whether or not there is hardware rendering support within dom0 still matters a lot. It affects window management/drawing latency.
1 Like
Agreed. I’m glad I’m not alone at least 