fedora18 performance / llvmpipe


I just got a Plugable UGA-2K-A (rev.B) usb 2 display adaptor to enable a third screen on my thinkpad x230 (with “dumb” docking station) and Fedora 18.

Plugging in the adaptor immediately gives me the option of the third screen in display proproties and enabling it works at full resolution, awesome. BUT performance is *atrocious* not only on the displaylink screen but all screens.

First thing I did was test fallback mode, and without 3d accelleration it works great, nice and smooth. Unfortunately I can’t work without gnome-shell (really once you get used to it it’s hard to go back to the old way).

Next thing I tried was disabling hwaccell in an xorg.conf for my HD4000 intel graphics, this forced LLVMpipe gallium driver to be used and it worked fine when the display link adaptor is not active, if i activate the adaptor in the display prefs, all displays power cycle a bit and go dark and the laptop completely locks up (pressing the power button causes a clean reboot however).

At this point, the only way forward I can see is to get displaylink working with the intel chip and both using llvmpipe nicely. Is there any way to acheive this?



Right now i am trying to use it with the sluggish window moving etc… but it’s pretty annoying… any way to speed it up?

Hi Alan,

Thanks for posting! Unfortunately, GDM fallback mode (or any non-composited desktop like MATE or Cinnamon) is the only way I know of to get good performance with USB graphics or VMs, etc. on Linux. See http://plugable.com/2012/06/11/fedora… for a prior post on this.

And it’s not a USB bus limitation – as you can see in fallback mode (which is fast), it’s not a bus bottleneck of getting the pixels across. It’s CPU / GPU load generated by GNOME 3.

When I compare performance on Linux to Windows or Mac (Mac kicked off the composited desktop craze, and Microsoft followed with Vista), Linux has a much bigger hit, and I can’t figure out why – it almost seems like GNOME 3 is re-rendering the whole screen for every screen for every page flip – even if nothing is changing. I can’t believe that’s the case, but it seems like it just from the performance effects.

So sorry, I’m not aware of a better answer – I see the same thing that GNOME 3 performance is atrocious – and a moving to a traditional window manager is the only solution that works today.

If you figure out any better solution, please post here to let others know.

Sorry for the bad news but hope that background helps,

Well, I think making it work with llvmpipe would be a solution… as you probably know already it allows the cpu to process the opengl stuff… on a core i7 that shouldn’t be a problem with 3 24" screens when you only care about getting smooth window motion :slight_smile:

If you could have a look at getting it working with llvmpipe I would be really pleased! It might be a good solution in general for all linux / displaylink users.

Edit: i see facebook broke their login system… had to login with g+ instead…

Hi Alan,

Thanks! We’ve had an opportunity to use llvmpipe on Fedora 17, so have some good data on that. Unfortunately, GNOME 3 is still a problem.

F17 introduced automatic USB multiseat support - you can plug in certain DisplayLink-based terminals (like http://plugable.com/products/dc-125 and http://plugable.com/products/ud-160-m/) and fresh logins will pop up.

On F17, this scenario is using llvmpipe for rendering (and udlfb to talk with the device). On F18, it’s the same as F18’s new multi-monitor support – it’s using DRM PRIME for rendering (using GPU) and udl DRM driver to talk with the device.

Unfortunately on F17 multiseat, if left at defaults, the same sluggishnes you’re seeing is there – and perhaps worse. Switching to fallback mode (non-compositing window manager) fixes the issue and makes everything snappy. That’s why we’ve had to recommend moving back to GNOME fallback mode for Fedora multiseat scenario (e.g. http://plugable.com/2012/08/19/switch…)

It seems that the problem is more at a higher level of the amount of pixel traffic GNOME 3 is generating (frequent refresh of most/all pixels, even when they’re not changing), which in the case of a PCI-based GPU probably isn’t noticeable (except as battery drain), but when you shift that load to the CPU and/or off PCI to USB – it drags systems down.

Again, sorry there isn’t a good solution we’re aware of for GNOME 3. Hope that background helps.

Well, suddenly it started working *really* smooth. Check this vid out that I took last night:


The adapter has been connected for more than 24 hours now but this morning when I came into work everything was back to being sluggish… very strange that it worked so nicely suddenly!

Wow! That’s interesting – it would be great if the performance problems with GNOME 3 were just a software bug at some level, and fixable.

That you were seeing a massive speed-up for several hours, then back to slow – it’s bizarre, but it points in the direction of a bug.

Let us all know if you find out any other patterns at all that might explain where the performance shifts …