From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 85320] [RV630] and RS880 GPU hangs using UVD hardware
acceleration
Date: Sat, 22 Nov 2014 14:15:59 +0000
Message-ID:
References:
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1891751982=="
Return-path:
Received: from culpepper.freedesktop.org (unknown [131.252.210.165])
by gabe.freedesktop.org (Postfix) with ESMTP id 7684D6E0D0
for ; Sat, 22 Nov 2014 06:15:59 -0800 (PST)
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
--===============1891751982==
Content-Type: multipart/alternative; boundary="1416665759.74Eb1.15804"; charset="UTF-8"
--1416665759.74Eb1.15804
Date: Sat, 22 Nov 2014 14:15:59 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=85320
D Rhodes changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[RV630] GPU hangs using UVD |[RV630] and RS880 GPU hangs
|hardware acceleration |using UVD hardware
| |acceleration
--- Comment #20 from D Rhodes ---
There was a VDPAU fix in MPV 0.6.1 that fixed this kind of lockup on my
hardware: RS880G.
My videos are all 1080i50 H.264 recordings from DVB-S2 broadcasts of various
channels. Since they are just chunks of transport stream, I think that lockups
when starting a video and when seeking would be similar.
Also I have ~oibaf MESA from 4th October, the first with the VAAPI state
tracker, and I tested that too. Here is a summary of what I found, with MPV
0.6.1
--hwdec=vdpau --vo=vdpau does not lock up the GPU but...
--hwdec=vdpau --vo=vdpau --deinterlace locks the GPU immediately.
I assume deinterlace will not work until there is a proper workaround for the
frame based output. UVD is not useful for me without deinterlace.
--hwdec=vaapi --vo=vaapi locks up the GPU quite often when starting to play a
video, similar to vdpau on MPV 0.6.0
--hwdec=vaapi --vo=opengl does not lock up the GPU but there is quite a lot of
coloured or speckled picture corruption on my video.
--
You are receiving this mail because:
You are the assignee for the bug.
--1416665759.74Eb1.15804
Date: Sat, 22 Nov 2014 14:15:59 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
D Rhodes
changed
bug 85320
| What |
Removed |
Added |
| Summary |
[RV630] GPU hangs using UVD hardware acceleration
|
[RV630] and RS880 GPU hangs using UVD hardware acceleration
|
Comment # 20
on bug 85320
from D Rhodes
There was a VDPAU fix in MPV 0.6.1 that fixed this kind of lockup on my
hardware: RS880G.
My videos are all 1080i50 H.264 recordings from DVB-S2 broadcasts of various
channels. Since they are just chunks of transport stream, I think that lockups
when starting a video and when seeking would be similar.
Also I have ~oibaf MESA from 4th October, the first with the VAAPI state
tracker, and I tested that too. Here is a summary of what I found, with MPV
0.6.1
--hwdec=vdpau --vo=vdpau does not lock up the GPU but...
--hwdec=vdpau --vo=vdpau --deinterlace locks the GPU immediately.
I assume deinterlace will not work until there is a proper workaround for the
frame based output. UVD is not useful for me without deinterlace.
--hwdec=vaapi --vo=vaapi locks up the GPU quite often when starting to play a
video, similar to vdpau on MPV 0.6.0
--hwdec=vaapi --vo=opengl does not lock up the GPU but there is quite a lot of
coloured or speckled picture corruption on my video.
You are receiving this mail because:
- You are the assignee for the bug.
--1416665759.74Eb1.15804--
--===============1891751982==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0
cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK
--===============1891751982==--