Certain Wayland apps/games fail with EGL_BAD_ALLOC

[TheComputerGuy96]

Hello,

I've initially been trying to figure out why running Minecraft with Wayland on my NVIDIA GPU didn't work, and it led to this issue being made

So certain Wayland apps/games (I tested Alacritty, osu!lazer and of course Minecraft) don't start when run on the NVIDIA GPU with PRIME

In GNOME/mutter, this error is shown: “failed to import supplied dmabufs: EGL failed to allocate resources for the requested operation.” And in sway: ‘importing the supplied dmabufs failed" (sway gives a EGL_BAD_ALLOC error for eglCreatelmageKHR in its logs which is probably the same error mutter is returning) (also sway points to the dri2_create_image_khr_texture function inside Mesa: The relevant function)

What's weird is that SuperTuxKart and Xonotic work and they definitely use Wayland

Running the apps listed above with XWayland (using WINIT_UNIX_BACKEND=x11 and SDL_VIDEODRIVER=x11; Minecraft is special because of GLFW) makes them work on the NVIDIA GPU

I'm not sure what logs/traces to give, so I'll just attach a Wayland debug log of Alacritty with both AMD and NVIDIA GPU being used: alacrittywlamd.log alacrittywlnv.log

And now time for the all important system info 🐸: Distro: Arch Linux egl-wayland version: 1.1.11 (1.1.10 also fails) Mesa version: 22.1.7 (trying the Git version also fails) Driver version: 515.76 Kernel version: 5.19.11 Compositor: mutter 42.5/sway 1.7 (with wlroots 0.15.1) CPU: Ryzen 5 4600H GPU: Renoir iGPU + GTX 1650 Ti Mobile (as I said a PRIME setup)

[erik-kz]

Thanks for the report. It's interesting that the issue is specific to certain applications. I tested alacritty on my local PRIME system and running it on the NVIDIA GPU does seem to work. Although that was with an Intel iGPU.

I'm wondering if maybe AMD has stricter requirements for the byte-pitch when importing buffers. By any chance, were games that worked using a different window size compared to the ones that did not?

[TheComputerGuy96]

@erik-kz I've done further testing with STK and discovered that screen/FB widths below 929 cause an error for some weird reason (so 800x600 crashes but not 1024x768 for example) 🐸

[erik-kz]

It looks like AMD requires that the pitch be aligned to 256 bytes, but for Wayland applications we only align it to 128 bytes currently. So, indeed, a 929-pixel wide buffer would get a pitch of 3840, which happens to also be divisible by 256, but a 928-pixel wide buffer would get a pitch of 3712 which is not divisible by 256. But some other smaller sizes should also work (e.g. 896 pixels wide).

Anyway, this should be fairly simple to fix. It will need to happen in the core EGL driver code, though, not egl-wayland. I'll try to get it in by the next release (525).

I will also look into including AMD + NVIDIA PRIME systems in our testing coverage, since it's unfortunate this issue was not caught earlier. Again, many thanks for bringing it to our attention.

[TheComputerGuy96]

@erik-kz 896 width actually works 🐸

[TheComputerGuy96]

Still present in 525.60.11 :(

[erik-kz]

Sorry, the fix didn't make it in in time for 525, but it will be in 530.

[TheComputerGuy96]

@erik-kz 530.30.02 driver fixes the issue, but egl-wayland commit b42f7ee48a67bb5129b12c111973ef627fc2dba7 causes a regression for some reason :thinking:

[TheComputerGuy96]

And egl-wayland 1.1.12 has the exact same issue as before 🐸

[erik-kz]

Does https://github.com/NVIDIA/egl-wayland/commit/ea70449fd94b5f866ea6189bf4f41f7c230cccfa resolve the issue, by any chance?