dx-packages team mailing list archive

[madbiologist <1123108@xxxxxxxxxxxxxxxxxx>]

Official support for Ubuntu 12.10 "Quantal Quetzal" and Ubuntu 13.04
"Raring Ringtail" has ended.  If anyone is still experiencing this issue
on Ubuntu 12.04 "Precise Pangolin" please check if this issue still
exists on Ubuntu 14.04 "Trusty Tahr".

Trusty has a 3.13-based kernel which introduced proper AMD Radeon DPM
(dynamic power management) for the first time.  Further Radeon DPM
improvements were made in subsequent kernels.  In particular, kernel
3.17 re-enabled DPM for AMD "Cayman", "Barts", "Turks" and "Caicos"
hardware after it was disabled in kernel 3.14 for stability reasons.
This is first included in Ubuntu 15.04 "Vivid Vervet" which is based on
the 3.19 kernel.

Anyone who still has this issue on Trusty (more likely for users with
Intel or NVIDIA hardware due to the reasons I outlined above), please
check that you are not running the fallback llvmpipe renderer by running
this command in a terminal window:

glxinfo |grep renderer

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dx-packages
https://bugs.launchpad.net/bugs/1123108

Title:
  unity slow on dual monitors (extended desktop)

Status in Unity:
  Confirmed
Status in unity package in Ubuntu:
  Confirmed

Bug description:
  I am running Ubuntu 12.10 64-bit on a desktop computer that has 7.3 GB
  of usable RAM, an AMD A8-5500 APU Radeon Quad-Core processor, and dual
  monitors at 1920x1080 each, one through DVI and the other through VGA.
  The hardware is more than capable of intensive work, however, I've
  noticed that ever since I did a fresh install, Unity will sometimes
  become a bit sluggish while doing animations, especially after coming
  back from suspend. The sluggishness does not make the computer
  unusable, but the slower animations are not pleasant. When I first
  boot the computer, it seems to work okay as far as I can tell.

  Normally, the animations are milky smooth, but when I suspend the
  computer and turn it back on, for example, the frame rate seems to
  drop quite a bit, especially if windows are animating across the
  entire screen or if I pop out the side bar, which is normally hidden.
  The lag in animation seems to affect the entire system, since the lag
  is also visible while using applications such as Firefox or Chrome.

  To fix the problem, I either have to 1) entirely restart the computer
  or 2) go to my display settings, select one of my monitors, disable or
  change its resolution, and then hit apply. Once I hit apply, the one
  screen flickers off and then on again (if I just changed the
  resolution), and then the lag seems to disappear. I can also revert
  the changes, letting the screen turn off and back on again, and the
  lag still seems to be gone. Sometimes, though, I may need to do this
  twice in order to get the frame rate completely back to normal.
  Another thing to note is that if I only use a single monitor instead
  of dual, this problem never occurs, even after waking the computer
  from suspend. The problem also seems to only occur when I am using the
  screens as an extended desktop, not mirrors.

  I first thought this issue could be due to a process utilizing too
  much of the CPU, so I ran 'top' but didn't notice anything very
  unusual about the results. While idle, the top processes are usually
  Xorg and compiz with about 0-3% CPU usage, and while windows are
  actively being moved and minimized/maximized across the screen, I've
  never seen Xorg go over about 30% and compiz about 15-20%.

  Also, I don't know if this has anything to do with this problem, but
  when I bring the computer back from suspend mode, an error flashes on
  the screen for only about half a second:

  [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu
  [Firmware Bug]: cpu 2, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu
  [Firmware Bug]: cpu 3, try to use APIC500 (LVT offset 0) for vector 0x400, but the register is already in use for vector 0xf9 on another cpu

  and it repeats. Again, not sure if it's relevant, but I thought I
  would mention it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/unity/+bug/1123108/+subscriptions