flathub / com.parsecgaming.parsec

https://flathub.org/apps/details/com.parsecgaming.parsec
12 stars 10 forks source link

VDPAU Support #9

Closed modzilla99 closed 2 months ago

modzilla99 commented 3 years ago

Hey there,

it seems that vaapi isn't working in this flatpak. That would be awesome to get working, how would I need to do that?

Thanks!

SISheogorath commented 3 years ago

I just updated the runtime of the flatpak, could you check if the problem still exists?

modzilla99 commented 3 years ago

I tried now and sadly it does not :( Do I need to add a permission to the flatpak?

grafik

EDIT: I tried with device=dri and without and it didn't change anything EDIT2: I just had a look at the Console and it said that VAAPI could not be opened on wayland, guess there's nothing you can do, or can you? I'll try on Xorg asap LASTEDIT: Yep works great on Xorg! Thanks mate!

egeexyz commented 3 years ago

This issue still exists with Nvidia cards as nvidia_drv_video is needed for hardware acceleration for us Nvidia users.

I'm working around this for now using the vdpau-va-driver package from Ubuntu Bionic since Canonical dropped support for it after 18.04.

Anything we can do to help with this issue?

Erick555 commented 3 years ago

I'm working around this for now using the vdpau-va-driver package from Ubuntu Bionic since Canonical dropped support for it after 18.04.

Flatpak runtime dropped support for it too.

changemenemo commented 3 years ago

I'm going to add my info fresh upgrade to fedora 34 I have this in console:

libva info: VA-API version 1.8.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/nvidia_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/GL/lib/dri/nvidia_drv_video.so
libva info: va_openDriver() returns -1
libva info: VA-API version 1.8.0
libva info: User environment variable requested driver 'vdpau'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/vdpau_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/vdpau_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/GL/lib/dri/vdpau_drv_video.so

So I guess I need symbolic link to make it work. What was the exact command line you launched @modzilla99 ?

EDIT: It's on a small card 1030 as client (not host, host it's a 2070 so we are good on that) but this card has hvec265 as nvidia x server settings is telling me and :

libva info: VA-API version 1.11.0
libva info: Trying to open /usr/lib64/dri/nvidia_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.11 (libva 2.11.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileMPEG4Simple            : VAEntrypointVLD
      VAProfileMPEG4AdvancedSimple    : VAEntrypointVLD
      <unknown profile>               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD

EDIT2: it would be nice that the flatpak ask for the host system OS and go look at the correct place for each OS like fedora it's /usr/lib64/dri/nvidia_drv_video.so

Does flatpak have access to the whole filesystem or do I need to allow it somehow with a specific command line in this context?

EDIT3: can't seem to make my symbolic link work.... it doesn't seem to see any of them. Would be nice to know if this flatpak is able to access the filesystem or not...

changemenemo commented 3 years ago

@SISheogorath coud you maybe give me some input here about that?

Erick555 commented 3 years ago

Does flatpak have access to the whole filesystem or do I need to allow it somehow with a specific command line in this context?

Flatpak doesn't have access to drivers from your host OS. You need to provide the drivers in flatpak.

changemenemo commented 3 years ago

@Erick555 shit that I did not know. I thought it was possible to give to some contianers some right with flatseal or something called like that... And how do you provide them with the drivers then if it s on the host filesystem?

Erick555 commented 3 years ago

You have to build them as part of the app. Whatever is on the host doesn't matter as flatpak has its own mesa/nvidia/vaapi.

changemenemo commented 3 years ago

@Erick555 then I don't understand what you mean by building them as part of the app, this means if I understand correctly, this is not my concern because I'm only doing bug testing here. If I need to rebuild the flatpak package by myself then (first I would not know how to it because I don't know anything about how this kind of package are built) and secondly the I would not need any flatpak in the first place. On my end every acceleration is working as intended on my linux client. It's only from in it the last version of this flatpak package that it has apparently problems to activate hardware decoding and vaapi. So besides building it from source, There is nothing I can do to improve the situation ?

changemenemo commented 3 years ago

@SISheogorath I understand that you are probably very busy but when you have th time could you maybe revert the changes that has been made so that we can recover the hardware acceleration at least in h264?

SISheogorath commented 3 years ago

@boistordu The problem we are facing here is caused by the runtime, not the application. The runtime, as far as I know, threw out "the old way of doing things" (iirc called vdpau) integration with version 20.08 due to deprecation of this system. The new way of doing things (which also the extensions "org.freedesktop.Platform.GL.nvidia-*" are for), need the application to be adapted to use these, which apparently Parsec didn't do. See: https://support.parsec.app/hc/en-us/articles/115002699032-Linux-Ubuntu-18-04

I'm by no means an expert in Graphics programming or the APIs that are or should be used for it, so feel free to correct me if I'm wrong. But Since we want to keep the runtime up-to-date, I don't think it's a good idea to roll-back the runtime. Especially since it's EOL in 3 months, when 21.08 is coming out. This needs movement from Parsec's side, there is not much I can do on a flatpak side.

Erick555 commented 3 years ago

So besides building it from source, There is nothing I can do to improve the situation ?

Yes, as user you can't do anything.

TiZ-HugLife commented 3 years ago

This is great for me to find out right as I'm about to play in a SoulCalibur VI tournament using Parsec. Still, the software H264 decoder is working fine and is not providing a huge amount of additional latency on my setup, and it's still miles better than SCVI's in game netplay, but it kind of stinks to found out this broke and doesn't have an easy fix.

DarkArc commented 3 years ago

This is great for me to find out right as I'm about to play in a SoulCalibur VI tournament using parsec. Still, the software H264 decoder is working fine and is not providing a huge amount of additional latency on my setup, and it's still miles better than SCVI's in game netplay, but it kind of stinks to found out this broke and doesn't have an easy fix.

I've been following this bug waiting for a resolution. I will comment that Rainway can be an acceptable general purpose workaround, moonlight is even better if your remote machine has an nvidia GPU, or if you can get sunshine working.

TiZ-HugLife commented 3 years ago

Ah yes, I'll get a tournament of over 90 people to change their infrastructure of 18 cloud VMs away from something that has been working super peachy for them less than an hour before the first pool starts. 😛

Fortunately, no hardware decode on my system is the difference between 1-2ms and 4-6ms decode. I can play in the tournament just fine, but it kind of stinks to find out a runtime change broke client app functionality.

SISheogorath commented 3 years ago

Mhm, so I got someone who is way more knowledgeable about this topic than I am, to explain the problem to me.

My original statement was wrong. Basically the runtime dropped a workaround that is "essentially an emulation VAAPI driver through calling relevant VDPAU API calls" from 2012, that takes a lot of maintenance time due to patching requirements.

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/19.08/elements/components/libva-vdpau-driver.bst

We could consider to bring this back, but the burden of maintenance would fall into the scope of this parsec flatpak. As I am neither a graphics developer, nor do I own any nvidia cards at the moment (and looking at the pricing, probably not any time soon), so I don't think I could maintain this is any meaningful way.

Which leaves the option of someone from the community stepping up or not including it and living the software decoding. In the meantime, one can try to push nvidia to implement VAAPI instead of insisting on their proprietary alternative or urge parsec to solve this problem in some other way.

changemenemo commented 3 years ago

I thanks you all for your answer. @SISheogorath Ow my mistake I thought it was because the good libraries was not packaged with your flatpak package. And so because of those libraries not being packed in your package it was thus impossible for parsec to being able to decode. But then you explain it more or less in a better way (still I would not understand why if you revert the package to 18.04 ubuntu which is still a LTS it won't work. And maybe even install the debian package from vaapi and si if it gives us some romme to breathe. Here it has been mentionned that https://github.com/flathub/com.parsecgaming.parsec/issues/11#issuecomment-817109080 the debian package was somehow compatible. And so we would be able to at least have the hardware decoder working. But maybe it's not working like that for flatpak package? In summary I meant that maybe we should bypass for some months (until we can bend the parsec team will about the upgrade) the integration to GL runtime from flatpak and just package everything needed in the flatpak package itself.

And I will work on the community forum of parsec to make things moving . So in the mean time, can we at least think about what's possible to do in a flatpak package? without relying on the GL runtime

And by the way 10-20ms in decoding +the encode time and the network time it's very difficult to do anything latency related.... even let's say a hunt: showdown little game

Erick555 commented 3 years ago

Neither ubuntu or debian packages have any relation to flatpak. The comment you mention was about fixing it for non-flatpak parsec on ubuntu host. Freedesktop 19.08 runtime will be officially EOL in 4 months but it doesn't get meaningful updates including mesa and security fixes even right now.

As it was said above fixing it within flatpak app is theoretically possible but it may need non-trivial work from someone who ideally have affected hardware. You have to find volunteer for this.

scy commented 3 years ago

I think this issue's title is misleading. VAAPI works. VDPAU however does not, at least not with Parsec (because they haven't implemented it). I've been talking to some of the Flatpak runtime devs and believe I can bring some clarification to this issue.

For some background, please see Hardware video acceleration in the Arch wiki.

VAAPI is the video acceleration API originally developed by Intel. It's supported by every GPU driver (Intel, AMD, Nouveau and ATI) except for the proprietary Nvidia drivers. These require VDPAU, developed by Nvidia.

Parsec only supports VAAPI. If you have an Nvidia GPU, they suggest you use a translation driver, which converts VAAPI calls to VDPAU calls. That thing is usually called libva-vdpau-driver, and this is what's been dropped from the Flatpak runtime. Apparently, it's notoriously unstable and nobody really wants to support it anymore.

Instead of relying on that translation layer, Parsec should implement both APIs, VAAPI and VDPAU. But they're lazy. ;) As a result, Nvidia users can't use hardware decoding with the Parsec Flatpak anymore. However, owners of other GPUs should still be able to have hardware decoding. It maybe just needs a little manual tweaking.

For example, I'm using an HD Graphics 615 GPU and did not have hardware acceleration at first. This is how my console output looked like:

$ flatpak run com.parsecgaming.parsec
[…snip…]
libva info: VA-API version 1.8.0
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
libva info: VA-API version 1.8.0
libva info: User environment variable requested driver 'vdpau'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/vdpau_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/vdpau_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/GL/lib/dri/vdpau_drv_video.so
libva info: va_openDriver() returns -1
[I 2021-06-10 18:34:25] * vaapi_init/WelsCreateDecoder[275] = -1
[D 2021-06-10 18:34:25] decoder       = software

There's an environment variable called LIBVA_DRIVER_NAME that can be used to manually tell VAAPI which driver to use. It looks to me (based on the driver_name = (null)) as if Parsec expects this variable to be set. If VAAPI can't be initialized successfully, Parsec apparently also tries to set LIBVA_DRIVER_NAME='vdpau' to try to invoke libva-vdpau-driver (which, as we've learned, isn't available in the Flatpak runtime anymore).

I then tried to launch Parsec while manually setting the driver, and that indeed allowed me to use hardware acceleration:

$ flatpak run --env=LIBVA_DRIVER_NAME=iHD com.parsecgaming.parsec
[…snip…]
libva info: VA-API version 1.8.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0

According to the flatpak-run man page, setting the environment variable on the host should also work (it will be passed on into the sandbox automatically), but I have not tested this yet.

You can install vainfo on your host machine, it should tell you the correct driver to use. Note that in my case, the host vainfo was using i965, but that didn't work inside Flatpak, I had to use iHD instead. (Which, as I'm told, is the superior driver anyway.)

There's also the Flatpak package org.freedesktop.Platform.VaInfo. It simply runs vainfo inside of Flatpak and can also give you some hints on whether your GPU is supported by the Flatpak runtime.

tl;dr: If you're using Intel, Nouveau, or ATI/AMD and hardware decoding isn't working for you, try setting LIBVA_DRIVER_NAME.

modzilla99 commented 3 years ago

Unfortunately that does not work on Wayland with an Intel GPU :( (LIBVA_DRIVER_NAME)

scy commented 3 years ago

Unfortunately that does not work on Wayland with an Intel GPU :(

I did my tests on Fedora 33 with Sway on Wayland. With an Intel GPU. Maybe your issue is something different.

TiZ-HugLife commented 3 years ago

I was able to use LIBVA_DRIVER_NAME=iHD on Xubuntu 20.04. I've got an Optimus setup, and even if I'm using NVIDIA to drive the Xorg server, the Intel GPU is still around to be used.

jgillich commented 2 years ago

Running parsec with --env=LIBVA_DRIVER_NAME=radeonsi on AMD does not work for me, I'm getting Vaapi unable to open Wayland display. on the console. According to vainfo I have a working driver and it works just fine under Xorg. Does anyone know what the issue here could be?

DarkArc commented 2 years ago

Running parsec with --env=LIBVA_DRIVER_NAME=radeonsi on AMD does not work for me, I'm getting Vaapi unable to open Wayland display. on the console. According to vainfo I have a working driver and it works just fine under Xorg. Does anyone know what the issue here could be?

I'm having this too, I opened https://github.com/flathub/com.parsecgaming.parsec/issues/14 as this seems unrelated to VDPAU.

entrhopi commented 2 years ago

This post on Reddit is mentioning that Parsec is currently transitioning to using FFMPEG. Not sure where this information is from, but that could explain why this stopped working ... https://reddit.com/w6dxhh

Kodikuu commented 1 year ago

Parsec dev here; The FFMPEG transition will hopefully be complete for the next update

I'm 99% done adding FFMPEG 3 Software, FFMPEG 4 Hardware, and FFMPEG 5 Software + Hardware. Currently the app only supports FFMPEG 4 via Software

DarkArc commented 1 year ago

Parsec dev here; The FFMPEG transition will hopefully be complete for the next update

I'm 99% done adding FFMPEG 3 Software, FFMPEG 4 Hardware, and FFMPEG 5 Software + Hardware. Currently the app only supports FFMPEG 4 via Software

I just wanted to say, that's really great news, and thank you for all your hard work (we appreciate it)!

Kodikuu commented 1 year ago

I hate to be the bearer of bad news, but while my FFMPEG work looks pretty good at this point, there just isn't enough "room" in the next update for it to go in.

It'll hopefully go out with 150-87, the update after next. This is not a guarantee or promise.

NightHammer1000 commented 1 year ago

I have done some testing with Kodikuu and pushed a little change to the build script. https://github.com/flathub/com.parsecgaming.parsec/pull/21

The new Version needs FFmpeg. This will include it in the Image.

SISheogorath commented 1 year ago

Thanks a lot for preparing this! Looking forward to the update :)

DarkArc commented 1 year ago

Parsec dev here; The FFMPEG transition will hopefully be complete for the next update

I'm 99% done adding FFMPEG 3 Software, FFMPEG 4 Hardware, and FFMPEG 5 Software + Hardware. Currently the app only supports FFMPEG 4 via Software

Hey @Kodikuu, I was just wondering if you had an update on this one? It's been a bit, and with the nvidia announcement about GameStream, finding a good streaming solution that can do H.265 is becoming increasingly important for me... Kinda hoping parsec can be that answer.

NightHammer1000 commented 1 year ago

From what I heared in the Discord it wont be until late Q1 2023

NightHammer1000 commented 1 year ago

But if they really decide to ditch it, I am sure work on https://github.com/LizardByte/Sunshine will pick up rather quickly. Its well usable already.

ZaxLofful commented 1 year ago

Any progress on this?

DarkArc commented 4 months ago

I've been using Sunshine + Moonlight; but for those waiting on this, looks like maybe this finally landed?

[Linux] Hardware support for FFMPEG 4-6.

https://parsec.app/changelog#150-94-0

Kodikuu commented 4 months ago

It's beginning to release today yes, but it will be a little while before everyone gets version 150-94.

Now I just need to look at adding FFMPEG 7 🙃

Kodikuu commented 2 months ago

The Flatpak runtime is updated, the Parsec installer too, and hardware should all be working now. VDPAU is available via FFMPEG 4, 5, and 6.