Wgpu-rs: Raspberry Pi 4 support

[DKolter]

Hello guys,

I have recently installed the vulkan broadcom driver for the raspberry pi 4 and tested it by running the Sascha-Willems demos. They ran without issue at high performance, the ImGui example ran at ~200 FPS. Relieved to move away from old OpenGL 2.1 to your modern library using the vulkan backend, I launched an example from imgui-wgpu-rs. It runs at 20 FPS with visual artifacts such as shapes flickering or tearing. I don't know where to start searching for the bug, whether the driver is to blame or the ash vulkan loader, so please help me fix that issue.

These examples were run on a fresh build from the recommended OS (32-bit) using the latest cargo and mesa driver available. I was able to reproduce the same effects using my other raspberry pi with an old build, so it doesn't seem to be local to my device.

Thanks in advance!

[kvark]

I imagine the Vulkan driver for Pi 4 is still fresh new, it may have gotchas depending on the code path taken, and we may be using Vulkan slightly differently from the demos you tested on previously.
You can help by doing the basic profiling. First, we need to find out if you are CPU or GPU bound. You can change the window size to see how it affects your frame rate. If it's GPU, we'll need to investigate the memory types we use versus ones the demos use. If it's CPU, we'll need to see which functions are responsible.

[cwfitzgerald]

See also: https://github.com/gfx-rs/wgpu/issues/1069. I've reported one of the corruption bugs to the Mesa bug tracker, but I haven't heard anything back from it, so I'm not too optimistic this will work any time soon. The gles backend is likely to work in a shorter time frame.

[DKolter]

Thanks for your fast response!
Changing the window size also changes the performance by a lot, if the window is very small (100x100), the FPS skyrockets to 2000, fullscreen reports 10 FPS. An OpenGL backend would indeed be a solution to this problem. I will check which function is responsible for the delay...

[kvark]

An OpenGL backend would indeed be a solution to this problem

Let's figure out what the problem is with Vulkan first. If the Vulkan demos work, we should be able to get it to work as well.
Maybe you could record VkTrace things to compare?

[DKolter]

I have tried it for hours now... VkTrace is a pain to find and build, it just keeps throwing compiler errors at me 😡. CMake does its best to avoid recognizing pthread, are there build instructions for Debian out there?

Edit: Attached CMake output

[kvark]

Last time I tried, building VkTrace was a pain as well, and I failed :) Anyhow, it was deprecated recently in favor of https://github.com/LunarG/gfxreconstruct . Would you want to try it?

[DKolter]

It worked ... after modifying LD_PRELOAD. The Sascha Willems demo (the working one) has some background model loading going on that greatly reduces the performance at the start (50 FPS), but after disabling it via ImGui, it jumps to 150 FPS. If needed, I could remove the model completely to make the comparison easier ...

• ImGuiWillems.zip
• ImGuiWillems2.zip
• ImGuiWgpu.zip
• ImGuiWgpu2.zip

[DKolter]

As far as I can see, they seem to use a completely different vulkan surface type: The working one uses a XcbSurfaceKHR and wgpu uses a XlibSurfaceKHR, might that be the main difference?

[kvark]

I wouldn't expect Xcb/Xlib difference to show up in frame times, but it's remotely possible, given that Window System Integration affects the delays in presentation and frame acquisition.

[DKolter]

Some posts on reddit etc. suggested to me that Xlib causes many performance issues on the Raspberry, is there a way to check whether that is the problem? I also noted that the wgpu version didn't enumerate the device properties, how does it then get the correct surface? When running vulkaninfo on the pi, the xcb surface is listed first, which causes the Willems demo to choose it as surface.

[kvark]

Technically speaking, wgpu-rs is not responsible for picking Xlib vs Xcb. You are feeding the RawWindowHandle, and we are using whatever you give us. So, to test Xcb, you'd need to find a way to convince winit (or whatever alternative) to produce an Xcb window. Nothing to be changed on our side here.

I also noted that the wgpu version didn't enumerate the device properties, how does it then get the correct surface?

What call exactly do you see us missing? AFAIK, we are enumerating everything.

[DKolter]

Thanks, that clarifies things, I was just wondering why the backtrace recorded vkCreateXlibSurface in the second line. I guess I will just wait for winit to support xcb then ...

[kvark]

Maybe you can try one of the SDL wrappers? Somebody must be able to create an XCB window. Perhaps, even using the x11::xcb directly would be a choice.