[V3D] Significant slowdown in the FreeRDP rendering

Start by reviewing the linked FreeRDP issue and reproducing the slowdown with the supplied xfreerdp command on the stated Pi 4, firmware, and 5.10.38-v7l kernel setup. Compare legacy, VC4-only, and V3D-enabled configurations as described; done means identifying the responsible kernel component and restoring rendering speed comparable to the VC4 configuration.

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

• Which model of Raspberry Pi? Pi4(00), possibly the Pi3b but since the Pi3 has proper VC4 driver support its not as impacted.
• Which OS and version (cat /etc/rpi-issue)? Raspberry Pi reference 2021-03-04 (All others will be effected to, except for images with a kernel that does not include V3D such as Thinlinx)
• Which firmware version (vcgencmd version)?
  Feb 25 2021 12:10:40
  Copyright (c) 2012 Broadcom
  version 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) (release) (start)
• Which kernel version (uname -a)? 5.10.38-v7l