From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 89987] Slow VDPAU
(rv770_restrict_performance_levels_before_switch failed)
Date: Sun, 09 Aug 2015 22:25:34 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0812980285=="
Return-path:
Received: from culpepper.freedesktop.org (unknown [131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id E13526E081
for ; Sun, 9 Aug 2015 15:25:33 -0700 (PDT)
In-Reply-To:
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel"
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org
--===============0812980285==
Content-Type: multipart/alternative; boundary="1439159133.bC7ea0.21518"; charset="UTF-8"
--1439159133.bC7ea0.21518
Date: Sun, 9 Aug 2015 22:25:33 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=89987
James Le Cuirot changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |NOTOURBUG
--- Comment #9 from James Le Cuirot ---
Sincere apologies for this but it looks like this is actually a bug in VLC.
Several factors threw me off, namely that mplayer isn't playing ball either
(don't know why yet), that I upgraded the kernel around the same time, that UVD
was introduced in 3.18, and the error in dmesg, all of which made it look like
a kernel problem.
Doesn't that mean it would have still been broken when going back to 3.17?
Actually it kinda was but not nearly as badly so I guess I didn't notice when
filing this bug. Under that kernel version, it looks as though it drops every
other frame in a smooth manner. Under recent kernels, it barely moves at all. I
started downgrading various userspace components like libvdpau, Mesa, and
xf86-video-ati to see whether any of those made a difference but it wasn't
until I downgraded VLC from 2.2 to 2.1 that the problem went away, both under
3.17 and 4.1. I also tried VLC git master under 4.1 and strangely it behaves
like 2.2 does under 3.17, dropping every other frame. Very confusing.
I am now bisecting to track down the precise cause.
--
You are receiving this mail because:
You are the assignee for the bug.
--1439159133.bC7ea0.21518
Date: Sun, 9 Aug 2015 22:25:33 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
James Le Cuirot
changed
bug 89987
What |
Removed |
Added |
Status |
NEW
|
RESOLVED
|
Resolution |
---
|
NOTOURBUG
|
Comment # 9
on bug 89987
from James Le Cuirot
Sincere apologies for this but it looks like this is actually a bug in VLC.
Several factors threw me off, namely that mplayer isn't playing ball either
(don't know why yet), that I upgraded the kernel around the same time, that UVD
was introduced in 3.18, and the error in dmesg, all of which made it look like
a kernel problem.
Doesn't that mean it would have still been broken when going back to 3.17?
Actually it kinda was but not nearly as badly so I guess I didn't notice when
filing this bug. Under that kernel version, it looks as though it drops every
other frame in a smooth manner. Under recent kernels, it barely moves at all. I
started downgrading various userspace components like libvdpau, Mesa, and
xf86-video-ati to see whether any of those made a difference but it wasn't
until I downgraded VLC from 2.2 to 2.1 that the problem went away, both under
3.17 and 4.1. I also tried VLC git master under 4.1 and strangely it behaves
like 2.2 does under 3.17, dropping every other frame. Very confusing.
I am now bisecting to track down the precise cause.
You are receiving this mail because:
- You are the assignee for the bug.
--1439159133.bC7ea0.21518--
--===============0812980285==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0
cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK
--===============0812980285==--