search

DisplayLink / evdi

Extensible Virtual Display Interface
MIT License
712 stars 185 forks source link

amdgpu and displaylink provide sad results #271

Closed mfs12 closed 8 months ago

mfs12 commented 3 years ago

Hey,

can you provide some idea when and if at you plan to fix your software to provide proper support amd-based linux systems?

I think there are quite some users out there sitting on their amd machines neither able to use displaylink-based docking stations nor multiple monitors.

What do you think about that?

BR

displaylink-emajewsk commented 3 years ago

Sad results indeed. We are very aware of the issues om amd. Unfortunately, we're spread mighty thin at the moment. I don't think we'll be able to fix it in the near future.

May I ask what distro are you using?

mfs12 commented 3 years ago

Sad results indeed. We are very aware of the issues om amd. Unfortunately, we're spread mighty thin at the moment. I don't think we'll be able to fix it in the near future.

Sorry, to hear that for you and us.

May I ask what distro are you using?

I am using Arch Linux.

displaylink-emajewsk commented 3 years ago

Ah, I wish we maintained an AUR ourselves. 😣

I'll try to press the amd issue internally after we're done with new kernel support.

mfs12 commented 3 years ago

Ah, I wish we maintained an AUR ourselves.

You could ask the maintainer to hand it over too guys. :)

I'll try to press the amd issue internally after we're done with new kernel support.

thanks and good luck... :+1:

bnavigator commented 3 years ago

Ah, I wish we maintained an AUR ourselves.

You could ask the maintainer to hand it over too guys. :)

It would be great if DisplayLink would support more distros than Ubuntu. The AUR PKGBUILDS can only work with what you give us. You are always welcome to use them for your testing and contribute with your own thoughts.

SEGELBERT commented 3 years ago

Hey,

i'd like to push this topic. The AMD performance is really sad. Clean Ubuntu 20.04 with Gnome and Up-To-Date Displaylink driver causes 50-90% CPU usage in idel.

My Notebook with USB Hub and 2 Displays is unusable... :(

best regards

sickcodes commented 3 years ago

Hey,

i'd like to push this topic. The AMD performance is really sad. Clean Ubuntu 20.04 with Gnome and Up-To-Date Displaylink driver causes 50-90% CPU usage in idel.

My Notebook with USB Hub and 2 Displays is unusable... :(

best regards

Try a lower resolution, that's pretty much the only solution, or a master CPU, or I think Wayland runs DL using the GPU, don't quote me though

spikerguy commented 3 years ago

think Wayland runs DL using the GPU, don't quote me though

If this is true then I am moving to Wayland right now :D

Even I am facing issue with AMDGPU it worked fine on 19" screen until Kde Plasma would lock up while on 24" screen it would lock up instantly. Displaying htop the whole columns are mixed up. My laptop is powerful enough to handle the displaylink though still need to dig into the error logs.

System:    Kernel: 5.11.10-1-MANJARO x86_64 bits: 64 compiler: gcc v: 10.2.0 
           Desktop: KDE Plasma 5.21.3 Distro: Manjaro Linux base: Arch Linux 
Machine:   Type: Laptop System: TUXEDO product: TUXEDO Pulse 14 Gen1 v: Standard 
           serial: <filter> 
           Mobo: TUXEDO s model: PULSE1401 v: Standard serial: <filter> 
           UEFI: American Megatrends v: N.1.06.A01 date: 10/13/2020 
Battery:   ID-1: BAT0 charge: 46.3 Wh (99.1%) condition: 46.7/46.7 Wh (100.0%) volts: 13.0 
           min: 11.4 model: standard status: Charging 
CPU:       Info: 8-Core model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64 type: MT MCP 
           arch: Zen 2 rev: 1 cache: L2: 4 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 92657 
           Speed: 1271 MHz min/max: 1700/2900 MHz boost: enabled Core speeds (MHz): 1: 1271 
           2: 1397 3: 1514 4: 1230 5: 1578 6: 1243 7: 1370 8: 1314 9: 1518 10: 1396 11: 1396 
           12: 1673 13: 1396 14: 1397 15: 1478 16: 1396 
Graphics:  Device-1: AMD Renoir vendor: Tongfang Hongkong Limited driver: amdgpu v: kernel 
           bus-ID: 04:00.0 
           Device-2: Chicony HD Webcam type: USB driver: uvcvideo bus-ID: 1-3:3 
           Display: x11 server: X.Org 1.20.10 driver: loaded: amdgpu,ati unloaded: modesetting 
           resolution: 1920x1080~60Hz 
           OpenGL: renderer: AMD RENOIR (DRM 3.40.0 5.11.14-1-MANJARO LLVM 11.1.0) v: 4.6 Mesa 21.0.2 direct render: Yes

Using DisplayLink HP Elite USB-C Docking Station with DL-3900 chip.

This is my laptop currently running 5.11 as I don't want it to keep crashing on me so until then I might have to just use the native HDMI output.

UPDATE: EVDI didn't work with Wayland :( Error log from dmesg

[   71.430594] evdi: [D] evdi_painter_framebuffer_size:581 Scanout buffer not set.
[   71.430598] evdi: [D] evdi_painter_mark_dirty:608 (dev=1) Skip clip rect. Scanout buffer not set.
[   71.439100] evdi: [D] evdi_painter_framebuffer_size:581 Scanout buffer not set.
[   71.439104] evdi: [D] evdi_painter_mark_dirty:608 (dev=1) Skip clip rect. Scanout buffer not set.
[   71.455119] evdi: [D] evdi_painter_framebuffer_size:581 Scanout buffer not set.
[   71.455124] evdi: [D] evdi_painter_mark_dirty:608 (dev=1) Skip clip rect. Scanout buffer not set.
[   71.574725] evdi: [D] evdi_painter_framebuffer_size:581 Scanout buffer not set.
[   71.574730] evdi: [D] evdi_painter_mark_dirty:608 (dev=1) Skip clip rect. Scanout buffer not set.
[   71.582669] evdi: [D] evdi_painter_framebuffer_size:581 Scanout buffer not set.
[   71.582674] evdi: [D] evdi_painter_mark_dirty:608 (dev=1) Skip clip rect. Scanout buffer not set.
[   73.161777] evdi: [D] evdi_painter_framebuffer_size:581 Scanout buffer not set.
[   73.161783] evdi: [D] evdi_painter_mark_dirty:608 (dev=1) Skip clip rect. Scanout buffer not set.
[furkan@furkan-pc ~]$ uname -a
Linux furkan-pc 5.10.26-1-MANJARO #1 SMP PREEMPT Thu Mar 25 16:56:17 UTC 2021 x86_64 GNU/Linux

Will switch to x11 and see if it works again without any reboot.

UPDATE2: Back to X11 and it works fine while kde plasma somehow crashes and gets the system stuck. I will dig deeper into this and get back. No luck with wayland though unless there is any specific pkg to be installed to make it work on wayland. @sickcodes please advice. Finally gave up on evdi and settled to hdmi output of the laptop itself. It keeps crashing plus shutdown never ends to power down the device.

Thanks.

mfs12 commented 3 years ago

Hey @displaylink-emajewsk , do you have any news for us poor AMD users?

spikerguy commented 3 years ago

New Update: The system crash was RTL8153 autosuspend not supported in the kernel. I blacklisted autosuspend and now dock seem to work fine. I will now look into the DisplayLink Performance on AMD Ryzen 7 4800H with Radeon Graphics Here is the screenshot of the htop over DisplayLink uxing X11 htop-displaylink

On Wayland I am not able to get any output of the display but the system detects a display and moves my workspace to it while I am not able to see anything.

Dmesg output over wayland

sudo dmesg | grep evdi
[sudo] password :
[    3.838824] evdi: [I] Initialising logging on level 5
[    3.838830] evdi: [I] Atomic driver: yes
[    7.013231] evdi: [D] evdi_crtc_init:413 drm_crtc_init: 0 p000000006656cad7
[    7.013251] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[    7.013260] evdi evdi.0: [drm] Cannot find any crtc or sizes
[    7.013272] evdi: [W] evdi_painter_send_update_ready_if_needed:706 Painter does not exist!
[    7.013583] [drm] Initialized evdi 1.9.1 20210126 for evdi.0 on minor 1
[    7.013611] evdi: [I] Evdi platform_device create
[    7.013613] evdi: [I] Attaching to usb:2-1.2
[    7.017125] evdi: [D] evdi_driver_postclose:230 (dev=0) Process tries to close us, postclose
[    7.017132] evdi: [I] Task 665 (Xorg) of process 665 (Xorg)
[    7.017591] evdi: [D] evdi_driver_postclose:230 (dev=0) Process tries to close us, postclose
[    7.017600] evdi: [I] Task 665 (Xorg) of process 665 (Xorg)
[    7.017889] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[    7.017983] evdi: [D] evdi_painter_framebuffer_size:594 Scanout buffer not set.
[    7.017986] evdi: [D] evdi_painter_mark_dirty:621 (dev=0) Skip clip rect. Scanout buffer not set.
[    7.017999] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[    7.018557] evdi: [D] evdi_painter_dpms_notify:715 (dev=0) Notifying dpms mode: 3
[    7.018562] evdi: [W] evdi_painter_send_event:321 Painter is not connected!
[    7.020134] evdi: [D] evdi_painter_dpms_notify:715 (dev=0) Notifying dpms mode: 3
[    7.020139] evdi: [W] evdi_painter_send_event:321 Painter is not connected!
[    7.020869] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[    7.020879] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[    7.031397] evdi: [D] evdi_painter_connect:851 (dev=0) Process is trying to connect
[    7.031402] evdi: [I] Task 649 (DesktopManagerE) of process 639 (DisplayLinkMana)
[    7.031471] evdi: [D] evdi_add_i2c_adapter:813 (dev=1) Added i2c adapter bus number 7
[    7.031473] evdi: [D] evdi_painter_connect:903 (dev=1) Connected with 00000000dc1522d2
[    7.031476] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[    7.033597] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[    7.033606] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[    7.033885] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[    7.033888] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[    8.020852] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[    8.020863] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[    8.021137] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[    8.021140] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[   24.578178] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[   24.578185] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[   25.296819] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[   25.296824] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[   25.356916] evdi evdi.0: cannot be used for peer-to-peer DMA as it is not a PCI device
[   25.361114] evdi: [D] evdi_painter_dpms_notify:715 (dev=1) Notifying dpms mode: 0
[   25.361124] evdi: [D] evdi_painter_mode_changed_notify:762 (dev=1) Notifying mode changed: 1920x1080@60; bpp 32; 
[   25.361129] evdi: [D] evdi_log_pixel_format:741 pixel format XR24 little-endian (0x34325258)
[   25.361133] evdi: [D] evdi_painter_dpms_notify:715 (dev=1) Notifying dpms mode: 0
[   30.149573] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[   30.149590] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  576.192940] evdi: [D] evdi_painter_dpms_notify:715 (dev=1) Notifying dpms mode: 3
[  576.264699] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  576.264704] evdi: [I] Task 665 (Xorg) of process 665 (Xorg)
[  576.287469] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  576.287477] evdi: [I] Task 6398 (Xorg.wrap) of process 6398 (Xorg.wrap)
[  576.304703] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  576.304710] evdi: [I] Task 6398 (Xorg) of process 6398 (Xorg)
[  576.343731] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  576.343739] evdi: [I] Task 6398 (Xorg) of process 6398 (Xorg)
[  576.388664] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  576.388668] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  576.388805] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  576.388805] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  576.431449] Modules linked in: ccm snd_seq_dummy snd_hrtimer snd_seq rfcomm uas usb_storage hid_plantronics cmac algif_hash algif_skcipher af_alg xt_CHECKSUM usbhid xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 bnep btusb btrtl btbcm btintel bluetooth ecdh_generic ecc xt_tcpudp uvcvideo snd_usb_audio videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_usbmidi_lib videobuf2_common snd_rawmidi snd_seq_device videodev mc ip6table_mangle ip6table_nat r8153_ecm cdc_ether usbnet ip6table_filter r8152 ip6_tables mii iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c joydev iptable_filter mousedev bridge stp intel_rapl_msr llc hid_multitouch iwlmvm snd_hda_codec_realtek evdi(OE) snd_hda_codec_generic intel_rapl_common asus_wmi wmi_bmof zram mac80211 clevo_wmi(OE) ledtrig_audnd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation soundwire_cadence snd_hda_codec libarc4 edac_mce_amd iwlwifi snd_hda_core kvm_amd
[  576.432082] evdi: [D] evdi_painter_dpms_notify:715 (dev=1) Notifying dpms mode: 3
[  585.107369] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  585.107379] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  585.107667] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  585.107669] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  585.107897] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  585.107899] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  585.563521] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  585.563527] evdi: [I] Task 6530 (Xwayland) of process 6530 (Xwayland)
[  620.586698] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  620.586704] evdi: [I] Task 1 (systemd) of process 1 (systemd)
[  621.361472] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  621.361479] evdi: [I] Task 6398 (Xorg) of process 6398 (Xorg)
[  621.386358] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  621.386370] evdi: [I] Task 9120 (Xorg.wrap) of process 9120 (Xorg.wrap)
[  621.397016] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  621.397022] evdi: [I] Task 9120 (Xorg) of process 9120 (Xorg)
[  621.406933] evdi: [D] evdi_driver_postclose:230 (dev=1) Process tries to close us, postclose
[  621.406939] evdi: [I] Task 9120 (Xorg) of process 9120 (Xorg)
[  621.470592] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  621.470598] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  621.470872] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  621.470874] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  629.816295] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  629.816300] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  630.572419] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  630.572431] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid
[  630.657721] evdi evdi.0: cannot be used for peer-to-peer DMA as it is not a PCI device
[  630.661790] evdi: [D] evdi_painter_dpms_notify:715 (dev=1) Notifying dpms mode: 0
[  630.661886] evdi: [D] evdi_painter_mode_changed_notify:762 (dev=1) Notifying mode changed: 1920x1080@60; bpp 32; 
[  630.661890] evdi: [D] evdi_log_pixel_format:741 pixel format XR24 little-endian (0x34325258)
[  630.661892] evdi: [D] evdi_painter_dpms_notify:715 (dev=1) Notifying dpms mode: 0
[  630.931941] evdi: [D] evdi_detect:90 (dev=1) poll connector state: connected
[  630.931948] evdi: [D] evdi_painter_get_edid_copy:242 (dev=1) EDID valid

Might use it with X11 and see how well it works for my daily task. BTW @DisplayLink-Admin https://displaylink.com seems dead.

sebastiano1972 commented 3 years ago

Hi,

I'd like to report that a similar issue exists with Fedora 33 + KDE Plasma.

My system is:

DisplayLink 5.4* and evdi v1.9.1 on Fedora 33 Kernel 5.11.15-200.fc33.x86_64 on Lenovo L14 Ryzen pro 4750U attached to Lenovo docking station USB C type 40AF with Display Link Chipset.

Seb

mfs12 commented 3 years ago

@displaylink-emajewsk Hey, are there any updates on the progress fixing this issues?

TheBITLINK commented 3 years ago

282 fixed the performance issues for me (Ryzen 3500U), though it's just a workaround for now.

bnavigator commented 3 years ago

There is a Manjaro user reporting that installing "Tuxedo Control Center" and some special settings helped with the performance issue: https://aur.archlinux.org/packages/displaylink#comment-806404

mfs12 commented 3 years ago

It would be also just interesting if displaylink is working on this issue at all.

spikerguy commented 3 years ago

There is a Manjaro user reporting that installing "Tuxedo Control Center" and some special settings helped with the performance issue: https://aur.archlinux.org/packages/displaylink#comment-806404 I am using Tuxedo Control Center on Manjaro and I have the same issue.

The user did not share which hardware he is using it on, Definitely not AMD.

I will try #282 fix and report back.

bnavigator commented 3 years ago

The user did not share which hardware he is using it on, Definitely not AMD.

"despite amdgpu"

MavropaliasG commented 3 years ago

Here's my system information. The performance is really bad, just by moving the mouse slowly in that screen uses ~15% of my CPU. Playing video is out of the question. Anything slightly moving, even a progress bar, lags my system a lot. Are there any plans to improve performance? It's basically unusable in its current state, only if you want a static page to show.

gdbd commented 3 years ago

Anyone experiencing performance issues have a look at https://github.com/DisplayLink/evdi/pull/282#issuecomment-843626578 This fix fixes the problem on X11 and I hopefully should be merged to master

mfs12 commented 3 years ago

@gdbd according to https://github.com/DisplayLink/evdi/issues/248#issuecomment-851665544 this is not true, problems reappear.

mfs12 commented 3 years ago

I'll try to press the amd issue internally after we're done with new kernel support.

@displaylink-emajewsk hey, did this problem make it meanwhile to your agenda?

opi99 commented 3 years ago

Any progress on this issue? With one monitor I get lags but with 2 monitors on the displaylink the system is unuseable.

mfs12 commented 3 years ago

Are there any recommendation to use amd ryzen with displaylink to fix the bad performance? Reading other issues here all people complain and there's no "real" work around? How is the current situation with wayland or xorg?

TheBITLINK commented 3 years ago

Are there any recommendation to use amd ryzen with displaylink to fix the bad performance? Reading other issues here all people complain and there's no "real" work around? How is the current situation with wayland or xorg?

@mfs12 check my comment in #293

mfs12 commented 3 years ago

@TheBITLINK thanks for your hint, unfortunately i am using i3wm and not gnome. And running experimental patches on work laptop is not really an option right now.

nikitagrygoriev commented 3 years ago

@mfs12 check my comment in #293 Just in case anyone stumbles upon this issue looking for help. Specs:

  • Fedora 34
  • Wayland
  • Gnome
  • Xiaomi Mi Laptop Pro 15 AMD

Fix no. 1 did not help. The stutter remains even after reboot. Overall performance is tragic on external monitors, while laptop screen works fine. Did not try fix no. 2, since I also use this laptop for work and that method sounds way too risky. Possibly, the best option for anyone wanting to use 4k and up monitors with AMD laptops is to wait for an eventual fix or buy a laptop with Intel/NVIDIA GPU.

irvis007 commented 3 years ago

I have never, ever thought I will (ever!) write it. Ever in my life :disappointed: but considering how long this issue is around, plus looks like it is not top priority, for dLink, plus if you do not want risk with fix no. 2, and on the end you or your company is not willing to buy new laptop, with Intel/NVIDIA GPU, Ashamedly alternative workaround: go Windows for some time, create some ~70-80GB partition and install temporary other family operating sys :scream:

I am desperate, I am using, docking station and kvm usb switch to easily switch set up (keyboard, mouse, monitors) between two laptops one private and second company one. I will not switch cables two times a day! first of all: it is annoying, second: unnecessary hardware degradation.

I have tried on private laptop two solutions, helped a bit, it is usable. On company one with AMD, not too much. So what has left?

EDIT: it is not an accusation for devs. I appreciate them work. Until this issue, I was more than happy about this soft. I am in place where I see no options, for a long time.

spikerguy commented 3 years ago

So should we just think that the displaylink device on my desk is just a usb hub without any display controller for linux?

Any update on this issue?

groovyman commented 3 years ago

From the customers view the displaylink driver is a piece of sh...t, also the Windows-10 driver has a couple of problems. Displaylink should better change their website, where they still promising Linux(ubuntu) driver. Displaylink could be understood as a scamware producer ...

From the manufactor side the competition against intel/apple's thunderbold technology seems to be a lost war. Thunderbold has a better throughput over a serial bus. Besides intel shows, what went wrong with Displaylink: intel worries about a good linux integration but Displaylank did not. So it does not surprise me, that the Displaylink driver stopped working when the Linux developer start migrating from X11 to Wayland because Displaylink seems not to spend any money for a linux developer, who worried about a good integration into linux.

Besides, when Displaylank offered a simple support on Linux, the developer was not experienced enough in Linux development. I did not understood, why any version of the driver was eating CPU time, while the Windows driver had less ressource consumption. There is no reason for CPU eating driver code, communication over any line should use dma, so there should be only little cpu load at all. So my understanding is, that the driver for linux was never good, anytime.

The compilation issue is another problem, that has to do with some code changes in the kernel. That can be fixed, actually the maintainer from evdi and displaylin(-rpm) fixed it. Anyway, the design of the linux driver seems to have a crappy design. Comparing the runtime behaviour with Windows shows, that there is something wrong. With a similar solution like the NdisWrapper for WLAN driver could be an intermediate solution for Displaylank.

I switched from Linux to Windows10 and i hate that situation at all. I want my KDE Desktop back again. Anyway i had to recognize, that the Display-Link offer good results and a very low CPU rate. Anyway, the driver has also bugs, but it offers a very good usability with 3 4K screens on a USB 3.1gen2 with 10Hb/s.

So please @displaylink-emajewsk , wake up and find a solution. Simply accept, that the linux driver is broken by design. I do not need thunderbold with 40Gb, the 10Gb is also working perfect for me and others. A good linux driver may be a solution for future products for embedded systems. Open your drivers and give better documentation.

mfs12 commented 3 years ago

Hey, any updates on this topic?

MikP0 commented 2 years ago

Having the exact same Issue here. CPU: AMD Ryzen 7 5800HS. Is that being looked at?

groovyman commented 2 years ago

I will try another solution, to use any notebook (regardless of its CPU) with a more simplier solution. If you own a notebook with a USB 3.x Gen y you may run at least 5Gbit or more over that connection. So the idea is to (cross-) connect it with a simple minipc over a crossbar USB3 cable and to establish a fast IP4 connection.

The idea is to run the mini-pc with a mini-linux, that is connected over a lan and by USB with the notebook. With my USB 3.2 Gen2 i could data 10 times faster, so first try was so connect a PC with 3 4K screen and connect it via FreeRDP with my Windows-notebook. xfreerdp /multimon /u:<user> /d:<domainname> /v:<notebook up> /gfx-thin-client /gfx-progressive /gfx:rfx

So this was a successful lowermark test, that showed, that i can run a remote RDP over 3 4K displays. The performance was similar these monitors, that are connected to my expensive docking station with one exception: the fullsize 4k Youtube video was bad and the IP load was extreme. But anyway, my USB-connectivity is 10 times faster ;-) So this was the Windows-test, how would i work with linux? From my point of view there are two possibilities:

Now, where is the hardware, that could play the role of a docking station, what about:

The price could be the same as you would pay it for a powerful docking-station. But the software would be more robust that this pice of joke, that is done by display-sleepy-link on linux.

TheBITLINK commented 2 years ago

The price could be the same as you would pay it for a powerful docking-station. But the software would be more robust that this pice of joke, that is done by display-sleepy-link on linux.

Thing is, there is no reliable way of creating a virtual display on amdgpu on Linux, maybe at compositor level it could be done, but not at driver level, which is what DisplayLink/evdi is doing.

You could create an RDP server or really just about any remote framebuffer protocol for that matter, but the difficulty lies on creating a virtual display that you can seamlessly attach to your existing environment just as if it was another monitor. You could create headless servers that do rendering off-screen, yes, but you wouldn't be able to easily move your programs or cursor between screens since they would be basically 2 separate environments. Either that, or cloning the main screen which would lose the whole purpose of having 2 screens in most cases.

The issue isn't really on DisplayLink's side either, it's the amdgpu driver that has issues with DMA on Linux with integrated GPUs. This issue affects not only DisplayLink, but really any other piece of software that wants to access the iGPU using DMA.

There are other projects that try to do exactly what you described (display over USB to a Raspberry Pi or other computer), for example https://github.com/notro/gud

But they have the same issues as evdi: slow copy from the GPU to the CPU, since they use the same method for accessing the GPU. Which is not really wrong, again it should work, and it does work with other GPU drivers, but not AMD. This bug has been an issue for a while now, and there are a few reports related to it on the mesa project, but so far nobody has looked into it.

Maybe there'll be more incentive on both DisplayLink's and AMD's side for fixing this once the steam deck (which also has an AMD APU) goes out, but I wouldn't really get my hopes up.

Ironically, this bug doesn't occur on AMD Chromebooks, and Chrome OS uses the exact same version of evdi that's in this repo, so they either fixed it at kernel level but didn't bother to upstream it, are using an older version of amdgpu that probably doesn't have this issue (the dmesg logs make it look like it's related to the peer to peer DMA-BUF feature introduced in Linux 5.2), or aren't using the kernel at all and doing everything at the compositor level.

Which by the way, there are ways to bypass DMA and let the compositor do the framebuffer copy. It takes a bit of CPU time and needs to be implemented by the compositor (so far I think only mutter allows it). That's exactly what the disable_texture_import=1 option does, it disables the buggy zero-copy DMA so the compositor can try a fallback method. If you have that option enabled and your compositor supports it, it will run at 60fps without an issue.

Even though the amdgpu driver is the main culprit here, I think it's also wrong on DisplayLink's side to not open-source the userspace DisplayLink manager, or at least the protocol used to communicate with the docks. The only thing that evdi does is create virtual screens and copy their framebuffers to whichever userspace programs need them. DisplayLink Manager is what actually communicates with the USB docks, it grabs the frames from evdi and sends them to the dock using their proprietary protocol. If we at least had the protocol specs, we wouldn't depend on evdi for getting the frames and might have found alternative ways to send frames directly to the device a long time ago, maybe even using mesa/DRM directly, like the udl driver does with older DisplayLink devices (not the new ones).

groovyman commented 2 years ago

Thank your for shwoing me your detailed point of view. I remember a presentation of a AMD engeneer, who gave a short overview of his work.

As you figured out, my siimle solution did not use the amd-gpu at all. But it was nice to see, that the performance was up to the mark for me, using

I was not able to see any performance difference betwenn W10 running on 3 4K Monitors using an expensive Docking-Station or use a local swith with a 1Gb subnet, where a Linux worksation rendered the Desktop over FreeRDP on the same monitors. Yes of course my solution failed, when showing a youtbe video in 4K resoution.) Do not get me wrong, i would love to see the dock running on Linux (if you want also without AMD-GPU as a work around).

agd5f commented 2 years ago

The issue is that you are trying to read from uncached memory with the CPU so reads will always be slow. On dGPUs the buffer is in VRAM which is an uncached PCI BAR mapping. On APUs, if the buffer is in carve out which is uncached CPU memory. The CPU read will only be fast if the buffer has a cached CPU mapping. Presumably this is what Intel integrated GPU hardware provides, so that's why it is faster. The reason https://github.com/DisplayLink/evdi/pull/282 helps is because it creates a cached CPU mapping of the memory. However, that is not safe because you don't have any cache coherency between the CPU or the GPU in this case. If you use the cached CPU mapping, you may end up getting stale data because the GPU is not set up to snoop the CPU's cache in this case.

Ideally you'd do the copy with DMA rather than the CPU (E.g., the displaylink driver provides a buffer that the GPU driver can DMA to or vice versa). If you absolutely need to use the CPU, you should use dma-buf to properly export the buffer from the GPU side and import it on displaylink side. That will cause the buffer to be migrated to cacheable system memory. This is how buffers are shared on hybrid graphics laptops (e.g., Intel + AMD or AMD + AMD). Displaylink devices are not fundamentally different. This is really something that should be fixed in the displaylink driver. Properly using dma-buf to share buffers would benefit any GPU driver, not just AMD. Things just happen to work ok today on Intel GPUs because they provide a cached mapping and none of their currently available GPUs have dedicated VRAM.

mfs12 commented 2 years ago

how are things progressing? was any of the issues fixed? how is the generic xorg and wayland support meanwhile? is it worth to give it another try?

groovyman commented 2 years ago

Well, the AMD ThinkPad T14s supports for a Alt-DP port. So better forget solution for old notebooks (using DisplayLink) and get a cheaper and more performant connectivity using Alt-DP. There is nothing wrong using DisplayLink for old notebooks, but if your notebook has a Alt-DP, forget DisplayLink, especially if your notebook uses a AMD Ryzen processor.

mfs12 commented 2 years ago

What is Alt-DP? I am using a AMD Ryzen 5 PRO 4650U with Radeon Graphics and a USB-C docking station.

groovyman commented 2 years ago

Some USB-C 3.1/2 connectors provides for a extension that is called DisplayPort Alternate Mode, that means, that your notebook uses some lines of the USB-C connection to transfer a DisplayPort signal side by side to the USB port.

see https://www.startech.com/en-us/blog/tech-talk-using-usb-c-and-displayport-over-alt

So for the newer notebooks (than come with USB-C alt dp support 1.2 and higher), there is no need to pack and transfer region of video-ram over the USB-C device, because you can use the DisplayPort signal, that can be used to transfer a digital video signal to multiple monitors over one cable. (i.e. using a MST docking station or daisy-chaining with DP).

For those notebooks let the AltDP controller do the job instead of wasting CPU time. So before you start: clarify which hardware controlling the USB-C dp line. I own a ThinkBook P16 with a AMD/Radeon & Nvidia configuration, where the ALT-C DP is controlled by the nvidia chip. In this case you have to use the proprietary Nvidia driver, because the open source Nouveau driver does not play with the Alt-DP for now. Also the Nvidia driver has some pitfalls, so there is some work to do.

But is even better that waiting in the wings for a solution for AMD cpus, that may not come (as a understood as AMD engeneer).

mfs12 commented 2 years ago

@groovyman thanks for the advice. I will test it as i found out my ryzen 4650u provides "DisplayPort alternate mode".

elveos commented 2 years ago

Had performance DisplayLink issues on Ryzen 5700U with its GPU on Manjaro 21.2.4 KDE with X11.

Finally works like a charm after making /etc/modprobe.d/evdi.conf containing: options evdi initial_device_count=2 vmap_texture=1 With 2 being number of displays using Displaylink, of course.

Drivers I'm using: aur/evdi-amd-vmap-texture 1.9.1.r6.g5490f94-1 (+1 0.10) (Installed: 1.9.1.r74.g64f6a62-1) aur/displaylink-beta 5.5.0-1 (+4 1.53) (Installed) Kernel: 5.15.25-1-MANJARO

groovyman commented 2 years ago

I would expect that a Ryzen 5700U would be part of a modern notebook, that comes with a USB-C AltDP socket, allowing you to connect an external display without any overcome transfer over a slow USB-3.x port. DisplayLink was a nice solution of old notebooks, but i assume, that you have own newer one.

spikerguy commented 2 years ago

Sadly no permanent solution was found and I have not used the dock for the core purpose of it which was display output.

Finally deciding to sell it off as I can buy a simple usb-c dock while just using the hdmi out of the laptop itself for 1/3 of the price paid for displaylink dock.

mfs12 commented 2 years ago

Hey @spikerguy, according to @groovyman you can use DisplayPort Alternate Mode.

Some USB-C 3.1/2 connectors provides for a extension that is called DisplayPort Alternate Mode, that means, that your notebook uses some lines of the USB-C connection to transfer a DisplayPort signal side by side to the USB port.

groovyman commented 2 years ago

Hey @spikerguy, according to @groovyman you can use DisplayPort Alternate Mode.

Some USB-C 3.1/2 connectors provides for a extension that is called DisplayPort Alternate Mode, that means, that your notebook uses some lines of the USB-C connection to transfer a DisplayPort signal side by side to the USB port.

You may find these connector mostly on AMD driven notebook, because the manufacteurs do not spent additional hardware for a USB4 connectivity. The Alt-DP signal is submitted over non USB lines and this is the best way to connect your notebook with external monitors, because you can use USB3.2 to connect your notebook with other devices.

DisplayLink is a bitter non working solution for most AMD users, because some of these notebooks use a Nvidia-Chip, that controls the video-ram. As far as i understand the DisplayLink technology is, that the driver has to dig into the nvidia-chip to access the videoram and the copy it via USB to the external docking station. So it is a better solution to install the nvidia driver, that is capable to deliver a Alt-DP signal over the USB3.2 sockets, that cost no CPU time at all.

lapsio commented 2 years ago

Has this been fixed? I see that https://github.com/DisplayLink/evdi/pull/351#issuecomment-1145503060 mentions it should work properly now? Could someone confirm that?

jakub-prussak-synaptics commented 8 months ago

I will close the issue for the time being, let us know if the problems are still appearing.