Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspberry Pi 4 support #1467

Closed
DKolter opened this issue Jan 18, 2021 · 15 comments
Closed

Raspberry Pi 4 support #1467

DKolter opened this issue Jan 18, 2021 · 15 comments
Labels
api: vulkan Issues with Vulkan external: upstream Issues happening in lower level APIs or platforms

Comments

@DKolter
Copy link

DKolter commented Jan 18, 2021

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
Copy link
Member

kvark commented Jan 18, 2021

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
Copy link
Member

See also: #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
Copy link
Author

DKolter commented Jan 18, 2021

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
Copy link
Member

kvark commented Jan 18, 2021

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
Copy link
Author

DKolter commented Jan 19, 2021

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
Copy link
Member

kvark commented Jan 19, 2021

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
Copy link
Author

DKolter commented Jan 20, 2021

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 ...

@DKolter
Copy link
Author

DKolter commented Jan 20, 2021

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
Copy link
Member

kvark commented Jan 20, 2021

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
Copy link
Author

DKolter commented Jan 24, 2021

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
Copy link
Member

kvark commented Jan 25, 2021

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
Copy link
Author

DKolter commented Jan 25, 2021

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
Copy link
Member

kvark commented Jan 25, 2021

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.

@kvark kvark transferred this issue from gfx-rs/wgpu-rs Jun 3, 2021
@kvark kvark added external: upstream Issues happening in lower level APIs or platforms type: bug Something isn't working labels Jun 3, 2021
@cymen
Copy link

cymen commented Apr 20, 2022

The issue for winit adding support for xcb is here rust-windowing/winit#5 (just adding to link these two issues together).

@cwfitzgerald cwfitzgerald added api: vulkan Issues with Vulkan and removed type: bug Something isn't working labels Jun 5, 2022
@cwfitzgerald
Copy link
Member

I think, from reading this, this is closable.

Patryk27 pushed a commit to Patryk27/wgpu that referenced this issue Nov 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: vulkan Issues with Vulkan external: upstream Issues happening in lower level APIs or platforms
Projects
None yet
Development

No branches or pull requests

4 participants