Go Back   DisplayLink Forum > DisplayLink Graphics Technology > Linux and Open Source

Reply
 
Thread Tools Search this Thread Display Modes
Old 06-16-2016, 01:32 PM   #21
mlukaszek
Senior Member
 
mlukaszek's Avatar
 
Join Date: Feb 2010
Posts: 384
Default

Having DisplayLinkManager process using more CPU with no device connected (what sanette reported) is not normal and we'll be looking into that.

To give context for remaining reports so far: DisplayLinkManager does some heavy lifting to talk to devices and push pixels to all additional screens connected to docking stations - so it will always need some CPU resources to do that.

We use EVDI as a kernel mode DRM driver which receives all notifications from standard Linux subsystems, including those telling there is a change on the screen that needs to be displayed. DisplayLinkManager gets those updates from EVDI, and uses them to refresh screens connected to DisplayLink devices.

The CPU usage is proportional to how much data we need to work with. Generally speaking, the more extra screens, the higher CPU usage.

Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.

Having full screens needing to redraw will also make the process use more resources than updating a fraction of the screen. Unfortunately, this again comes back to the quality of screen update notifications we receive on Linux - even if the thing changing is tiny, if we're told that we should update the entire screen, we must do as we're instructed.

Having said all that...

We are currently looking at possibilities of reducing the CPU usage on Linux, but first would like understand what CPU usage (and overall performance) are people getting on different setups. Therefore, we'd need your help!

If you see something that you don't like please record a short video (smartphone quality is just fine) and share here. This will let us see how things work on your systems.

Some caveats:
Having Ubuntu's "Display Properties" window opened makes the CPU usage high - as the app is rendering an overlay with a display number on each screen - massively increasing the number of screen updates.

If using Unity desktop environment - for reasons explained above - even having a cursor blinking in console, or "top" window updating itself regularly on the internal screen will cause updates for all DisplayLink screens, too.

Regards,
Michal

Last edited by mlukaszek; 06-16-2016 at 01:37 PM.
mlukaszek is offline   Reply With Quote
Old 06-16-2016, 03:11 PM   #22
Sparxy
Junior Member
 
Join Date: Jun 2016
Posts: 12
Default

Hi Michal,

I am using the XFCE desktop environment, which is rather lightweight so I'm not sure whether the amount of CPU usage I'm getting could be considered within normal range. This is why I'm checking in.
This also begs the question whether there's no way for DisplayLink to optimize the drivers to detect which parts of the screen changed more accurately, causing less need for constant screen updates?

Thank you for your help.
Sparxy is offline   Reply With Quote
Old 06-22-2016, 09:02 AM   #23
cpo
Junior Member
 
Join Date: May 2016
Posts: 6
Default

Sorry, I gave up on this stuff. I've some work to do currently. No time to experiment with various DisplayLink issues. Fact is that if you work, you'll have some applications open. Browsers with several tabs, multiple terminals, maybe an IDE (intellij in my case), a mail client, chat, etc. I've a 21:9 screen with 2560x1080 pixels on it.

It turned out that the current DisplayLink integration isn't made for my setup. It feels like a proof of concept. Maybe it's ok do simple presentations over it. I don't know why you need a video to understand what ~30fps means. Its just slow. And eats up CPU cycles. And the notebook battery.

Finding applications that may lead to high CPU load because they do things "different" isn't an argument if you need these applications.

That's valid at least for the USB3 connected D3100. I've the Dell USB-C connector, too. But I never got it running with the external screen because of kernel oupses when the HDMI cable is plugged and all screens black.

As a result, I'm running the Notebook without any external screens for three months now. Still having the hope that it will get usable some time.
cpo is offline   Reply With Quote
Old 06-27-2016, 03:16 PM   #24
Sparxy
Junior Member
 
Join Date: Jun 2016
Posts: 12
Default

I was able to greatly improve performance by disabling the default XFCE compositor. However, this causes the issue described in http://displaylink.org/forum/showthread.php?t=64586

Last edited by Sparxy; 06-27-2016 at 03:35 PM.
Sparxy is offline   Reply With Quote
Old 07-29-2016, 09:21 AM   #25
lloydwatkin
Junior Member
 
Join Date: Jul 2016
Posts: 1
Default

Quote:
Originally Posted by mlukaszek View Post
Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.
I have installed Gnome 3.20 on Ubuntu 16.04 and am happy to report that CPU usage has dropped dramatically (it was at around 180%). I shall report on stability once I've used it a bit more. Previously my external monitors would freeze regularly with killing the main displaylink process and unplugging the dock the only way to turn them back on.
lloydwatkin is offline   Reply With Quote
Old 08-14-2016, 02:31 AM   #26
asdfwadfawdf
Junior Member
 
Join Date: Aug 2016
Posts: 6
Default

Quote:
Originally Posted by mlukaszek View Post
Having DisplayLinkManager process using more CPU with no device connected (what sanette reported) is not normal and we'll be looking into that.

To give context for remaining reports so far: DisplayLinkManager does some heavy lifting to talk to devices and push pixels to all additional screens connected to docking stations - so it will always need some CPU resources to do that.

We use EVDI as a kernel mode DRM driver which receives all notifications from standard Linux subsystems, including those telling there is a change on the screen that needs to be displayed. DisplayLinkManager gets those updates from EVDI, and uses them to refresh screens connected to DisplayLink devices.

The CPU usage is proportional to how much data we need to work with. Generally speaking, the more extra screens, the higher CPU usage.

Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.

Having full screens needing to redraw will also make the process use more resources than updating a fraction of the screen. Unfortunately, this again comes back to the quality of screen update notifications we receive on Linux - even if the thing changing is tiny, if we're told that we should update the entire screen, we must do as we're instructed.

Having said all that...

We are currently looking at possibilities of reducing the CPU usage on Linux, but first would like understand what CPU usage (and overall performance) are people getting on different setups. Therefore, we'd need your help!

If you see something that you don't like please record a short video (smartphone quality is just fine) and share here. This will let us see how things work on your systems.

Some caveats:
Having Ubuntu's "Display Properties" window opened makes the CPU usage high - as the app is rendering an overlay with a display number on each screen - massively increasing the number of screen updates.

If using Unity desktop environment - for reasons explained above - even having a cursor blinking in console, or "top" window updating itself regularly on the internal screen will cause updates for all DisplayLink screens, too.

Regards,
Michal
I opened Ubuntu bug 1613001
Ubuntu 16.04 LTS, Intel HD Graphics 4000, 1 LVDS laptop display, 1 HDMI, 1 HDMI through DisplayLink USB 3.0.

Quote:
root 19733 49.1 0.4 2167260 49476 ? Ssl 17:09 127:33 /usr/lib/displaylink/DisplayLinkManager
DisplayLinkManager uses significantly more CPU than everything else and mouse cursor flickers on all displays (LVDS and HDMI) but DisplayLink.

Any workaround so far?
asdfwadfawdf is offline   Reply With Quote
Old 08-14-2016, 04:00 AM   #27
asdfwadfawdf
Junior Member
 
Join Date: Aug 2016
Posts: 6
Default

I switched to gnome 3.18 by installing ubuntu-gnome-desktop, cpu utilization barely changed

Quote:
root 3405 34.7 0.3 2138928 48668 ? Ssl 23:20 7:45 /usr/lib/displaylink/DisplayLinkManager
I don't think switching from Unity to Gnome made any difference. When I browse something like Google Earth on non-displaylink displays, DisplayLinkManager still causes CPU spike

Last edited by asdfwadfawdf; 08-14-2016 at 04:47 AM.
asdfwadfawdf is offline   Reply With Quote
Old 08-15-2016, 10:54 PM   #28
dcastellani
Junior Member
 
Join Date: Jul 2016
Posts: 3
Default

Wanted to add my own experience.

On my desktop, running Antergos, basically Arch Linux, I am also experiencing extremely high CPU usage around DisplayLinkManager.

My setup is, three monitors, primary monitor is plugged directly into my desktop via DVI. Two monitors in portrait mode plugged into Dell D3100 via DVI to HDMI adapters. Displays are rotated via xrandr.

When moving just the mouse on the primary monitor, connected via DVI to the desktop GPU, DisplayLinkManager spikes to around 130%. My desktop is running an i7-2600k 4 cores, 8 threads.

This also occurs when moving windows/mouse on the actual monitors plugged into the display links.
dcastellani is offline   Reply With Quote
Old 08-21-2016, 05:56 AM   #29
asdfwadfawdf
Junior Member
 
Join Date: Aug 2016
Posts: 6
Default

And why is displaylinkmanager using 15% CPU when it is not even connected?
asdfwadfawdf is offline   Reply With Quote
Old 08-24-2016, 10:08 AM   #30
trepseq
Junior Member
 
Join Date: Aug 2016
Posts: 8
Default

Same problem here using HD3000 and Ubuntu 16.04 with unity. Will try out gnome to see if there is a difference.
trepseq is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 01:45 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.