Louvre on a hybrid i915/nouveau system

[yurikhan]

I have built Louvre (d69b475) on Ubuntu 24.04 (development). My laptop has hybrid graphics, integrated Intel GPU (i915 driver) and NVIDIA (nouveau). Intel drives the built-in 3840×2160 panel, and NVIDIA drives an external 5120×2880 monitor over (mini) DisplayPort. (Also has an HDMI output, but I wasn’t able to achieve 5K over that, so not using it.) On X11, both monitors give me 60 FPS.

When I start Firefox and navigate to https://www.testufo.com/, under louvre-views, it displays an exorbitant FPS value fluctuating between 150 and 512. The animation speed also fluctuates.

The expected behavior is a steady 60 FPS animation on both displays. (Frustratingly, other Wayland compositors, including GNOME/Mutter, Sway/wlroots and Hyprland/wlroots, give me 60 FPS on the built-in panel and about 15–20 FPS on the external monitor.)

Does that look like some unimplemented feature or protocol in Louvre, or am I doing something wrong?

[ehopperdietzel]

Interesting, I tried it on my computer a moment ago, and the same thing happens, but only in Firefox (300 fps avg). From Google Chrome, it shows 60 fps. Could you try it on Google Chrome? Or another browser? I will analyze what might be happening.

[ehopperdietzel]

Alright, I've identified the issue. The problem stems from both Firefox and Louvre. The issue lies in the fact that Firefox sends multiple wl_surface::frame requests in succession and before a wl_surface commit, without waiting for a response from the compositor. As a result, Louvre responds to ALL of these frames after rendering the window and then waits for Firefox to send another one. I've made a modification so that Louvre now responds to only one frame at a time, achieving 60 fps.

I implemented this partly for security reasons, as if a client generates frames at a rate higher than they are destroyed, it could potentially exhaust the compositor's memory (in an extreme case). Therefore, my solution will be to respond one at a time but impose a limit on how many can live simultaneously. If it exceeds this limit, Louvre will begin to respond/destroy more than one frame at a time.

Thank you for noticing btw. I'll upload the corrected version, most likely tomorrow or the day after, in release 1.2.0-1.

[ehopperdietzel]

Great haha! The same happens to me when Nouveau imports DMA buffers. Even if the PRIME cap flags indicate a value of 3, SRM conducts a brief test to determine if it can import/export buffers with GBM/EGL. This test sometimes fails, even when it claims to support it (I believe Nouveau has an option to enable/disable GBM/EGL support during compilation). Consequently, those values may get overridden. Specifically for Nouveau, I had disabled that feature due to this bug, but using the SRM_ALLOCATOR_DEVICE env should no longer disable it by default.

Now, regarding Firefox, I believe it uses the linux-dma-buf Wayland protocol, so it defines the DMA buffer parameters like width, height, stride, offset, etc. Louvre then passes these parameters to SRM using srmBufferCreateFromDMA(), and internally, this function uses this EGL extension for converting it to an OpenGL texture.

The thing is that if the same DMA parameters are passed to the i915 and Nouveau drivers, and the former successfully imports them while the latter fails (displaying that glitch), then the issue seems to lie with Nouveau, unless it requires something else, such as an additional offset or similar which I don't know.

[ehopperdietzel]

If you would like to try hacking SRM to see if you can import them correctly in Nouveau, the functions where this is handled are srmBufferCreateFromDMA() and srmBufferGetTextureID(). Essentially, srmBufferCreateFromDMA() only defines the parameters of the buffer. Then, when srmBufferGetTextureID() is called, depending on the GPU, it creates the specific OpenGL texture for that GPU or simply returns it if it has already been created before. So that is where the DMA importing takes place.

https://github.com/CuarzoSoftware/SRM/blob/main/src/lib/SRMBuffer.c

[yurikhan]

I added debug logging in srmBufferCreateFromDMA, srmBufferCreateFromCPU, and srmBufferGetTextureID, just to see what real world data looks like. Some observations:

• All buffers I have seen had a single plane.
• Buffers created from CPU have rows aligned to 256 bytes.
• Buffers created from DMA have rows aligned to 4 bytes (one physical pixel).
• If I map the data into memory and dump the pixel data to files before the call to eglCreateImage, the data appears to correspond to the declared stride.
• When I resize a window by dragging its edges with my mouse, the smallest increment I can achieve is 2 physical pixels. I suspect resizing happens in 1-unit increments in surface coordinates, which are then scaled.
• On the external screen, a window is displayed correctly if its buffer width is a multiple of 8 physical pixels (and its stride a multiple of 32 bytes). Otherwise, it is distorted at angles of 2:1, 4:1 or 8:1.
• I found a 6-year-old Mesa-dev thread discussing a similar issue.
• I also tried hacking the Louvre code to restrict resizing windows to 4-unit multiples. Unfortunately, that part of the code works in surface units and window geometry, and the full buffer size comes out a bit unpredictable. For some windows, it gets me correct rendering; for others, consistent distorsion. I’m not currently sure how to fudge window sizes in the compositor so that texture strides come out as multiples of 32 bytes (considering fractional scaling), and if popups will pose an additional problem.

Where do DMA buffers come from? Does the client allocate them using some well-known API? Maybe that API can be persuaded to overalign?

[ehopperdietzel]

Wow, you went above and beyond with your research. If what you're saying is accurate, then it sounds like bad news. As you mentioned, the only hope would be to compel the client to always use a stride with that multiple. I'm not exactly sure how Firefox creates those buffers, but it's likely using the wayland-egl platform, which I think uses the wl_drm protocol to authenticate an fd and obtain permissions to allocate buffers (I assume with that fd wayland-egl makes the same calls to the driver as GBM does). Then, if the linux-dma-buff protocol is also present, it uses it to share the fd and buffer parameters with the compositor.

If you look at the API for clients, you can see that it has no control over the stride, so it must be calculated internally by the implementation:

https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/egl/wayland-egl-core.h

Now, this is good because there could be some environment variable or configuration that allows forcing a specific stride. But if you look at the implementation, it must depend on the specific driver used:

https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/egl

In my case, the buffers are displayed correctly, probably because they are created by the Nouveau driver and then imported by i915, which apparently has no issues. However, in your case, it seems that Nouveau does not support creating DMA buffers, or at least the GBM implementation (you mentioned everything turns black when Nouveau is the allocator device), but maybe it can be enabled if you compile it manually.

[yurikhan]

I’m getting the impression that clients just call GBM directly, over one of the devices in /dev/dri. Firefox has an environment variable to override which one it uses, which I have not yet tested.

I’ve looked into Mesa’s libgbm and it looks like it lets the user to specify a backend library via the GBM_BACKEND environment variable. It might be possible to implement one that wraps the Mesa implementation.

Although it’s not just Firefox that has a problem. Nautilus (the GNOME file manager) also gets distorted on the external screen, and I’m pretty sure it uses stock GTK+. So many dependencies to chase 😅

[yurikhan]

In the bad case [SRM_ALLOCATOR_DEVICE=/dev/dri/card1], this message is repeated many times:

SRM warning: [/dev/dri/card1] Directly mapping buffer DMA fd failed. Trying gbm_bo_map.

This message is written from two places in SRMBuffer.c, one in CreateFromCPU, the other in CreateFromGBM. With my additional logging, I notice that the one that is firing is in CreateFromCPU.

Also, when a syscall or a libc function fails, they usually set errno. I logged that and it turns out that the two mmap calls fail with EACCES (Permission denied). Does that tell you anything?

[ehopperdietzel]

So definitely the issue must be with SRM, can you tell me specifically which distribution you are using? If I try the same one, maybe I can replicate the error here and solve it.

[ehopperdietzel]

It's also weird that elevated privileges aren't required to write to those devices. Typically, only the root user or members of the video group can do that. Could you share the output you get by running ls -l /dev/dri?

[yurikhan]

Sorry for long response times, I’m back to work and finding fewer opportunities to tinker.

My devices in /dev/dri:

total 0
drwxr-xr-x   3 root root        140 Jan 21 20:30 .
drwxr-xr-x  22 root root       5580 Jan 21 20:30 ..
drwxr-xr-x   2 root root        120 Jan 21 20:30 by-path
crw-rw----+  1 root video  226,   0 Jan 21 20:30 card0
crw-rw----+  1 root video  226,   1 Jan 21 20:30 card1
crw-rw----+  1 root render 226, 128 Jan 21 20:30 renderD128
crw-rw----+  1 root render 226, 129 Jan 21 20:30 renderD129

and I don’t think I’m in the video or render groups. Despite that, directly calling open(2) on these devices succeeds 🤷‍♂️

I’m on Ubuntu 24.04.

[ehopperdietzel]

No need to worry, perhaps that '+' at the end is granting permissions via ACL. Anyway, when I find the time, I'll test your distribution to see if I can resolve it, and I'll provide you with an update.

[ehopperdietzel]

Hi, I still haven't tried to solve the issue, but I just remembered that you can get considerable higher FPS by enabling triple buffering, you can do that by setting SRM_RENDER_MODE_ITSELF_FB_COUNT=3 (for displays connected to your Intel card) and SRM_RENDER_MODE_DUMB_FB_COUNT=3 for nvidia (since I remember it was using dumb buffers in your case), just use the main SRM branch.