search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11k stars 4.95k forks source link

[V3D] Significant slowdown in the FreeRDP rendering #4353

Open henk717 opened 3 years ago

henk717 commented 3 years ago

Is this the right place for my bug report? The bug i am describing only occurs when V3D is compiled in the kernel, because it is not related to 3D graphics my assumption is that this bug report does not belong to mesa. If this is wrong let me know and i will open a bug report there. On the FreeRDP github is an existing bug report related to this issue you can find here : https://github.com/FreeRDP/FreeRDP/issues/5917

The reason i am also filing this bug report here is because the bug does not occur on other devices and does not occur when the kernel is compiled exclusively with the VC4 driver (the seperate V3D driver left out), or when the raspberry pi is configured to use legacy video mode and thus bypassing V3D altogether. To further clarify, V3D in the configuration can be left enabled and the bit of code for V3D inside the VC4 driver is not causing this issue as long as the kernel is not compiled with its seperate V3D driver. This will then result in a configuration that does automatically detect monitor resolutions but does not suffer of this slowdown.

Describe the bug This bug effects the rendering speed of FreeRDP, this is mostly tested with the /GFX parameter but seems to be present on all their rendering modes and is most notable on larger screen resolutions like 1080P and above. You will visibly see the frames be drawn in from top to bottom and while this tearing effect can be observed on the VC4 driver the speed of this draw in the V3D driver is significantly slower. An easy way to observe this is to also use the /network:auto parameter which allows window dragging and dragging a window across the screen. On the VC4 config you will be able to quickly shake a small window without problems and with at most some small delay or screentearing. On the V3D config you will see each frame update from top to bottom making the entire session very unresponsive to all actions performed.

To reproduce To reproduce i recommend using the official raspbian image and updating this image to its testing repository, this will allow you to install the freerdp2-x11 package which will be version 2.3 instead of the old and unstable 2.0.0-beta5. (I can also provide a custom compiled version if need be). You will also need a Windows 10 based system with remote desktop enabled.

Use the following command line to connect to the system : xfreerdp /v:IP-Here /u:UsernameHere /p:Passwordhere /cert-ignore /f +wallpaper /gfx:avc420 /network:auto (or /network:lan for even more effects) . This should give you a consistent experience to test with, you can use other /gfx options but the effect will remain the same.

Switch between the legacy driver and the V3D driver using raspi-config to observe the speed differences, or switch between a kernel that does not have the V3D module and the default kernel settings as supplied by this github.

Expected behavior The screendraw times are at least as fast as the old VC4 driver and preferably faster on the Pi4 given the VC4 implementation relies fully on software acceleration of the other elements in the desktop.

Actual behaviour The screendraw times are slow and you will see the screen refresh from top to bottom as the frames are being drawn in, significantly slowing down all tasks including simple tasks like dragging a small window.

System

daradib commented 2 years ago

Thanks. I was similarly able to workaround by blacklisting the v3d module and rebooting:

echo 'blacklist v3d' | sudo tee /etc/modprobe.d/blacklist-v3d.conf

You could also add module_blacklist=v3d to /boot/cmdline.txt

Nabla128k commented 2 years ago

Hi. Is there anything new regarding this issue? Now we have 64bit version of Raspberry OS where it's not solution disable/blacklist v3d, because it uses mutter window manager and it's performance is unusable without v3d. So as a result freerdp is not usable on raspberry os 64bit.

daradib commented 2 years ago

Agreed, Raspberry Pi OS 11 uses mutter for compositing. You can revert back to openbox by editing window_manager in /etc/xdg/lxsession/LXDE-pi/desktop.conf. However, the loss of hardware acceleration also negatively impacts chromium and vlc.