| Priority | medium |
|---|---|
| Bug ID | 74335 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | [UVD] vdpau hangs the system on radeonsi (HD 7950) |
| Severity | normal |
| Classification | Unclassified |
| OS | All |
| Reporter | darkbasic@linuxsystems.it |
| Hardware | Other |
| Status | NEW |
| Version | XOrg CVS |
| Component | DRM/Radeon |
| Product | DRI |
Follow up of https://bugs.freedesktop.org/show_bug.cgi?id=71448 Here is a video which hangs 100% of the times: https://mega.co.nz/#!eQhSjJQR!EEe8-taN5IspIu-RW0WQzmvKzc5fkCn282kS5ugZ_as Play with mplayer2 -vo vdpau, -vc ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau, PlanetEarthBirds.mkv
Created attachment 93297 [details]
startx
This is my pure X server so I fear it's not going to happen.
Anyway I just got two more crashes with KDE (one with desktop effects ON and
one with desktop effects OFF) and then it worked for a couple of times.
Anyway it's way too slow (I get "Your system is too SLOW to play this!" in
mplayer).
Video works perfectly on my 7870. Are you sure that's not an unrelated bug? Please try running it without any desktop effects. Best way to narrow it do= wn would be a pure X server without anything else started.
| What | Removed | Added |
|---|---|---|
| Summary | [UVD] vdpau hangs the system on radeonsi (HD 7950) | [UVD] vdpau has terrible performance on radeonsi (HD 7950) |
I switched from libav/mplayer2 to ffmpeg/mplayer git and the crash seems gone. Bye bye libav. Being stable I did some more tests and unfortunately performance sucks so I renamed the bug report. Benchmarking the video output: ffh264 software decoder + gl/xv/vdpau ~ $ mplayer -benchmark -nosound -lavdopts threads=16 PlanetEarthBirds.mkv -vo gl BENCHMARKs: VC: 3.403s VO: 7.530s A: 0.000s Sys: 0.672s = 11.605s BENCHMARK%: VC: 29.3238% VO: 64.8892% A: 0.0000% Sys: 5.7870% = 100.0000% ~ $ mplayer -benchmark -nosound -lavdopts threads=16 PlanetEarthBirds.mkv -vo xv BENCHMARKs: VC: 7.878s VO: 2.162s A: 0.000s Sys: 1.040s = 11.080s BENCHMARK%: VC: 71.0951% VO: 19.5154% A: 0.0000% Sys: 9.3896% = 100.0000% ~ $ mplayer -benchmark -nosound -lavdopts threads=16 PlanetEarthBirds.mkv -vo vdpau BENCHMARKs: VC: 0.863s VO: 43.888s A: 0.000s Sys: 0.550s = 45.300s BENCHMARK%: VC: 1.9042% VO: 96.8823% A: 0.0000% Sys: 1.2135% = 100.0000% With both -vo gl and -vo xv it took ~11.080s while with -vo vdpau it took 45.300s. -vo vdpau is *4x* slower. Benchmarking the video decoder: ffh264/ffh264vdpau + vo null ~ $ mplayer -benchmark -nosound -lavdopts threads=16 PlanetEarthBirds.mkv -vo null BENCHMARKs: VC: 8.855s VO: 0.002s A: 0.000s Sys: 0.493s = 9.350s BENCHMARK%: VC: 94.7024% VO: 0.0262% A: 0.0000% Sys: 5.2714% = 100.0000% ~ $ mplayer -benchmark -nosound PlanetEarthBirds.mkv -vo null -vc ffh264vdpau It seems I can't use the null video output with the hardware decoder ffh264vdpau: I get tons of "Too many buffered pts". It does support only -vo vdpau, not even xv or gl. Such a pity. (is it a known limitation/bug?) Let's do a more complete benchmark: ffh264+xv vs ffh264vdpau+vdpau We already saw ffh264+xv took 11.080s, let's see how ffh264vdpau+vdpau performs. ~ $ mplayer -benchmark -nosound PlanetEarthBirds.mkv -vo vdpau -vc ffh264vdpau BENCHMARKs: VC: 0.869s VO: 44.581s A: 0.000s Sys: 0.374s = 45.824s BENCHMARK%: VC: 1.8955% VO: 97.2876% A: 0.0000% Sys: 0.8169% = 100.0000% As expected it's still 4 times slower because the bottleneck is obviously the vdpau video output and not the ffh264vdpau decoder. Being 4x slower vdpau is completely useless right now :( Please note that I disabled desktop compositing before doing the tests.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
UVD IRQs weren't working correctly on SI. Bug is fixed upstrea= m by new kernel release.
(In reply to comment #5= ) > Is it fixed in 3.16-rc6? That fix should be in all kernels since 3.14. It was named "drm/radeon= : fix UVD IRQ support on SI".
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | REOPENED |
| Resolution | FIXED | --- |
Ah, stop my fault. That was for the other bug report. Sorry, I've just messed those two up.
ArchLinux x86-64; linux 3.16; mesa git; llvm svn; Radeon HD 7950 Is it still correct? I have: $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo gl BENCHMARKs: VC: 3.404s VO: 17.792s A: 0.000s Sys: 1.978s = 23.174s BENCHMARK%: VC: 14.6908% VO: 76.7753% A: 0.0000% Sys: 8.5339% = 100.0000% $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo xv BENCHMARKs: VC: 10.609s VO: 3.479s A: 0.000s Sys: 1.867s = 15.955s BENCHMARK%: VC: 66.4934% VO: 21.8045% A: 0.0000% Sys: 11.7021% = 100.0000% $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau BENCHMARKs: VC: 3.319s VO: 16.936s A: 0.000s Sys: 0.644s = 20.900s BENCHMARK%: VC: 15.8826% VO: 81.0336% A: 0.0000% Sys: 3.0837% = 100.0000% $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo null BENCHMARKs: VC: 11.915s VO: 0.003s A: 0.000s Sys: 0.653s = 12.571s BENCHMARK%: VC: 94.7809% VO: 0.0228% A: 0.0000% Sys: 5.1963% = 100.0000% $ mplayer -benchmark -nosound -lavdopts threads=16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau -vc ffh264vdpau BENCHMARKs: VC: 7.402s VO: 13.679s A: 0.000s Sys: 0.692s = 21.773s BENCHMARK%: VC: 33.9957% VO: 62.8252% A: 0.0000% Sys: 3.1791% = 100.0000%
mplayer -benchmark -nosound -lavdopts threads=3D16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo gl=20=20 BENCHMARKs: VC: 0.827s VO: 22.917s A: 0.000s Sys: 0.494s =3D 24.23= 8s BENCHMARK%: VC: 3.4108% VO: 94.5502% A: 0.0000% Sys: 2.0390% =3D 100.000= 0% $ mplayer -benchmark -nosound -lavdopts threads=3D16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo xv BENCHMARKs: VC: 3.292s VO: 2.707s A: 0.000s Sys: 0.667s =3D 6.66= 6s BENCHMARK%: VC: 49.3886% VO: 40.6098% A: 0.0000% Sys: 10.0016% =3D 100.000= 0% mplayer -benchmark -nosound -lavdopts threads=3D16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau BENCHMARKs: VC: 0.752s VO: 22.925s A: 0.000s Sys: 0.482s =3D 24.15= 8s BENCHMARK%: VC: 3.1113% VO: 94.8942% A: 0.0000% Sys: 1.9945% =3D 100.000= 0% mplayer -benchmark -nosound -lavdopts threads=3D16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo null BENCHMARKs: VC: 4.836s VO: 0.004s A: 0.000s Sys: 0.391s =3D 5.23= 1s BENCHMARK%: VC: 92.4320% VO: 0.0849% A: 0.0000% Sys: 7.4831% =3D 100.000= 0% mplayer -benchmark -nosound -lavdopts threads=3D16 Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau -vc ffh264vdpau BENCHMARKs: VC: 1.624s VO: 22.466s A: 0.000s Sys: 0.501s =3D 24.59= 0s BENCHMARK%: VC: 6.6026% VO: 91.3590% A: 0.0000% Sys: 2.0384% =3D 100.000= 0%
That looks normal, I have that sample and it's 1444 frames / 6= 0Hz =3D 24 seconds. You can't really turn off vsync for vdpau and mplayer doesn't do gl interop. Cpu times can mislead if cpufreq on_demand is in use as you don't know what freq the cores are in. UVD/powerplay is tuned for playback (at least on recent GPUs) if using with= eg. ffmpeg you can get more perf by forcing GPU clocks to high.
| What | Removed | Added |
|---|---|---|
| Status | REOPENED | RESOLVED |
| Resolution | --- | FIXED |
Yeah, agree. The number look perfectly fine. Additional to that please don't reopen a three year old bug for this.
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | CLOSED |