You are not logged in.

#1 2017-08-26 19:19:19

khmer
Member
Registered: 2017-08-26
Posts: 9

[SOLVED] Weird behavior vdpauinfo

Im setting up hardware video acceleration on my laptop with a kaby lake I5-7300U cpu. when i check if its setup right with vdpauinfo i get a strange output saying it doesnt support pretty much anything but H264. pastebin.com/WRU7FQXM.
I assume this isnt normal, how can i fix it so i have support for the other formats? Heres the output of vainfo for comparison, pastebin.com/CfxuaggL .

Last edited by khmer (2017-08-26 20:50:13)

Offline

#2 2017-08-26 19:29:17

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: [SOLVED] Weird behavior vdpauinfo

Intel doesn't support VPDAU. That vdpauinfo shows anything means you have libvdpau-va-gl installed, in which case uninstall it. It's a crappy wrapper, even when it does work (it often doesn't), it does so with such poor performance that it removes any benefit of hardware decoding.

Offline

#3 2017-08-26 20:11:39

khmer
Member
Registered: 2017-08-26
Posts: 9

Re: [SOLVED] Weird behavior vdpauinfo

Gusar wrote:

Intel doesn't support VPDAU. That vdpauinfo shows anything means you have libvdpau-va-gl installed, in which case uninstall it. It's a crappy wrapper, even when it does work (it often doesn't), it does so with such poor performance that it removes any benefit of hardware decoding.

The wiki mentioned that its recommended to keep both of them installed, do you think it should be disregarded?

Offline

#4 2017-08-26 20:29:11

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: [SOLVED] Weird behavior vdpauinfo

I know what the wiki says. But hardware decode wrappers are a source of bad performance, non-working applications (libvdpau-va-gl doesn't work with at least VLC, for example) and just plain confusion.

Offline

#5 2017-08-26 20:49:11

khmer
Member
Registered: 2017-08-26
Posts: 9

Re: [SOLVED] Weird behavior vdpauinfo

ill take your advice on it then, thanks for the help!

Offline

#6 2017-08-27 21:13:59

i-rinat
Member
Registered: 2013-07-16
Posts: 26

Re: [SOLVED] Weird behavior vdpauinfo

Gusar wrote:

It's a crappy wrapper, even when it does work (it often doesn't), it does so with such poor performance that it removes any benefit of hardware decoding.

Sigh. Your words are hurting my feelings, you know. :-)

If you happen to use hwdec-enabled path, it's fine. Although could be better, I admit. But from numbers I can't say it's too bad. Just tested on Quantum of Solace trailer. Mpv with all-software decoding uses about 50% CPU, with vaapi+vaapi (hwdec and vo) it's about 5-6%, and with vdpau+vdpau (through libvdpau-va-gl) it's about 9-10%. I wouldn't say it's removing benefit of hardware decoding.

Of course there are situations, where using libvdpau-va-gl will hurt performance. For example, if CPU have no integrated GPU with decoding capabilities. In that case colorspace conversion will be performed by unoptimized code in libvdpau-va-gl rather than utilizing GPU's Xv pipeline. Or if player for some reason decides to read picture back to CPU memory (VLC sometimes does that to apply video filters). That will hurt a lot. But why would anyone use hardware decoder if data is then downloaded back from the GPU?

Generally, what you are speaking about is somewhat right: if your machine have native VA-API drivers, you're better off with using VA-API path, if available. But the wording you've chosen... they are far from fair.

Offline

#7 2017-08-28 16:07:05

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: [SOLVED] Weird behavior vdpauinfo

i-rinat wrote:

Sigh. Your words are hurting my feelings, you know. :-)

Well, every time I checked out libvdpau-va-gl it didn't perform that well. Maybe CPU usage went down, but it was offset by higher GPU usage.

I'll admit it's possible that my words are harsher than the actual situation. But that's because I've seen too many times people having problems because they used a wrapper where a native driver is available. So I discourage the use of wrappers when it comes to hardware decoding.


To cheer you up, I do use one wrapper you wrote that works excellently - freshplayer. Due to Firefox's crappy video pipeline (it's all software and possibly far from what even a software solution could provide), using freshplayer on Youtube made a significant difference. Sadly it "made" a difference, as Google recently shut down flash-based playback on Youtube. Another of your wrappers seems to be working well too - apulse. I haven't needed to use it personally yet, but it may happen someday.

So even though I speak against using libvdpau-va-gl, I still consider you king of wrappers smile

Offline

#8 2017-08-28 21:58:33

i-rinat
Member
Registered: 2013-07-16
Posts: 26

Re: [SOLVED] Weird behavior vdpauinfo

Gusar wrote:

Maybe CPU usage went down, but it was offset by higher GPU usage.

That's the point — to offload computations from CPU to the GPU. GPU may be doing more — for example, scaling on GPU involves a lot more floating point operations that the same procedure on CPU — but that's workload GPU's are optimized more. Overall power consumption and heating goes down. Hopefully.

Gusar wrote:

as Google recently shut down flash-based playback on Youtube

Well, they kind of did that. But currently it's just some variables in the code switched from "false" to "true". Reversible.

// ==UserScript==
// @name        Disable HTML5 video on Youtube
// @namespace   ri
// @include     https://www.youtube.com/*
// @version     1
// @run-at      document-start
// @grant       none
// ==/UserScript==

(function () {
  // Disable Youtube's Flash killswitch.
  var patch_scripts = function (e) {
    if (e.target.text.indexOf('indexOf("web_player_flash_fallback_killswitch=') === -1) {
      e.target.text = e.target.text.replace(/web_player_flash_fallback_killswitch=true/, 'nothing_in_particular=true');
    }

    if (e.target.text.indexOf('indexOf("web_player_disable_flash_watch=') === -1) {
      e.target.text = e.target.text.replace(/web_player_disable_flash_watch=true/, 'nothing_in_particular=true');
    }
  }

  document.addEventListener('beforescriptexecute', patch_scripts, true);
  
  // Pretend HTML5 video can't play anything.
  var canPlayType = function (type) {
    return '';
  }
  document.createElement('video').constructor.prototype.canPlayType = canPlayType;
  document.createElement = function (create) {
    return function () {
      if (arguments[0].toLowerCase() == 'video') {
        var r = Object();
        r.canPlayType = canPlayType;
        return r;
      }
      return create.apply(this, arguments);
    };
  }(document.createElement);
})();

Single-page operations are broken. Don't know whenever they are broken due to the script, or they are just broken for the Flash version.

Offline

#9 2017-08-30 15:44:05

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: [SOLVED] Weird behavior vdpauinfo

i-rinat wrote:

That's the point — to offload computations from CPU to the GPU.

Actually, no it isn't. GPUs don't decode video, a dedicated video decode ASIC does that accompanies the GPU does. Without wrappers, GPU usage is the same whether software or hardware decoding is used. The GPU does the same work in both cases, it's just decoding that moves from CPU to dedicated ASIC.

i-rinat wrote:

Overall power consumption and heating goes down. Hopefully.

That's just it, it didn't go down, due to the rise in GPU usage. So instead of reducing power consumption, the wrapper just moved where the consumption happens. Whereas non-wrapped hardware decoding does reduce consumption.

i-rinat wrote:

Well, they kind of did that. But currently it's just some variables in the code switched from "false" to "true". Reversible.

Ha, I kinda knew there's some wacky scripts to enable flash floating around smile

Offline

#10 2017-09-01 20:22:43

i-rinat
Member
Registered: 2013-07-16
Posts: 26

Re: [SOLVED] Weird behavior vdpauinfo

Gusar wrote:

Actually, no it isn't. GPUs don't decode video, a dedicated video decode ASIC does that accompanies the GPU does.

Actually, you don't know that. Nobody really knows how decoder actually works on Intel chips. Their VA-API driver has a lot of shader code, some with sources, some without. It's not clear whenever actual decoding is performed by specialized hardware unit, or there are specialized instructions in shader processors that help to decode bitstream. In Fedora they ditched the driver because they fear that some of decoding may be in software.

Next, it's i915 driver you need to talk to, when sending commands. GPU's rings are used for data transfer. Even if there is a specialized IP block, I'd say it's part of GPU. :-) Also, I noticed that "bitstream busy" metric was available when I had Ivy Bridge chip, but not available now with Skylake. Either they decided to hide it in newer intel-gpu-tools version, or there is no way to measure its usage in Skylake. There is a single "render busy" now.

Next, for many years already, XVideo's colorspace conversion is performed by shader core. There were times when specialized hardware did that, but now it's easier to ditch that hardware and just use shader processors. And even without using any of those, you are using GPU to just show anything on screen. That's not eating so much, isn't it?

Gusar wrote:
i-rinat wrote:

Overall power consumption and heating goes down. Hopefully.

That's just it, it didn't go down, due to the rise in GPU usage. So instead of reducing power consumption, the wrapper just moved where the consumption happens. Whereas non-wrapped hardware decoding does reduce consumption.

Can't say for sure what went wrong.

My experience is the opposite. I did experimenting with libswscale scaling vs. scaling on GPU. I for sure know that libswscale does smaller amount of computations for the same job than GPU. But GPU has large number of simple calculators, which do the task using less amount of energy.

My guess is that in your case decoded frames were read back to the CPU memory. For example, if you ask mpv to use decoding via vdpau, but output via opengl, there will be reading decoded frames back. vdpau+opengl combination will work fine on NVIDIA proprietary drivers though, since they control both libGL and VDPAU driver. They way their opengl-interop works is by adding a set of extensions to OpenGL. vdpau+vdpau should work fine with libvdpau-va-gl (and of course with NVIDIA drivers).

Upd.

i-rinat wrote:

Also, I noticed that "bitstream busy" metric was available when I had Ivy Bridge chip, but not available now with Skylake.

I think I found a bug. Another tool from the same toolset reads "bitstream busy" metric just fine.

Last edited by i-rinat (2017-09-01 22:13:29)

Offline

Board footer

Powered by FluxBB