ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.22k stars 174 forks source link

Use hardware encoding on AMD RX480 for In-Home Streaming. #4890

Closed toojays closed 2 years ago

toojays commented 7 years ago

My GPU is an RX 480. When streaming to the steam link from Linux, my streaming_log.txt shows:

[2017-03-09 22:54:10] >>> Capture method set to Desktop OpenGL NV12 + scale + libx264 main (3 threads)
[2017-03-09 22:54:10] >>> Capture resolution set to 1280x720

Whereas from Windows, I get:

[2017-01-12 06:55:24] >>> Capture method set to Steam D3D10 NV12 + AMF H264
[2017-01-12 06:55:24] >>> Capture resolution set to 1920x1080

Unsurprisingly, I get a better picture, and smoother performance when streaming from Windows.

Recent versions of Mesa support hardware encoding of H264 on this GPU:

┌(toojays@kano)─(9993)─(0)─(2017 03 10 20:16:12)
└─(~)─> vainfo | grep Entry
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      <unknown profile>               : VAEntrypointVLD
      <unknown profile>               : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

Please enhance the Steam Linux client to take advantage of this for streaming to the Steam Link.

kisak-valve commented 7 years ago

Hello @toojays, there shouldn't be a distinction in the steam client between this video card and other AMD cards that use mesa. You may want to confirm that hardware encoding is enabled in the Advanced Host Options of the In-Home Streaming settings.

Plagman commented 7 years ago

We don't currently support VA-API for encoding, but it's a valid feature request, thanks.

toojays commented 7 years ago

@kisak-valve, are you saying hardware encoding is supported on this card? Perhaps by some means other than VA-API?

It do have it enabled in the settings. I have not seen any report of any Linux user having hardware encoding working on any AMD GPU, so have assumed it is not supported. Which is consistent with Plagman's comment, unless perhaps it's supported with the proprietary drivers or something. I asked about the requirements for it at http://steamcommunity.com/groups/homestream/discussions/0/1842367319523385800/ and heard nothing.

kisak-valve commented 7 years ago

@toojays, all I said was that the RX 480 model should currently have the same support as other AMD video cards using mesa, nothing more.

toojays commented 7 years ago

It sounds like that for now that support is limited to there being a tantalizing checkbox which does nothing. ;)

I look forward to that checkbox being wired up to enable actual hardware encoder support code at some point in the future.

Plagman commented 7 years ago

That checkbox does enable other backends such as NVENC, but nothing that currently works on Mesa to my knowledge.

xenithorb commented 6 years ago

Can anyone enumerate the roadblocks for this feature here?

Bengt commented 6 years ago

I see the same behavior on an AMD Radeon R9 Nano with the current AMDGPU-Pro drivers. It also supports H.264 encoding via VA-API:

~$ vainfo
libva info: VA-API version 0.39.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.0)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileNone                   : VAEntrypointVideoProc

When using the "beautiful" option in FullHD, the PC I want to use it on, reports a load of 300 %. This means that the CPU resources of my Phenom II X6 1090t get cut in half:

bildschirmfoto vom 2018-01-04 20-25-13

The significantly increased power consumption of the software encoding causes more noise output. My PC screaming after me impairs the success of Steam Link of moving away from it. To me, this makes Steam Link kind of pointless.

In the performance overlay on the Steam Link, I the frame rate drop from 60 to 30 or even lower when much of the screen content changes quickly. When I start a 3D game, it runs fine if at only 30 FPS on the host PC, but Steam Link sees 1 % packet loss, which results in 40 % frame drops and is obviously unplayable. Steam Link estimates the bandwidth of my Gigabit switch at up to 68 MBit/s, so that does not seem to be cause of the the issue.

Bengt commented 6 years ago

The massive benefit enabling hardware video encoding under Linux would have for users like me can be seen in the response to enabling it under Windows for AMD cards:

https://steamcommunity.com/app/353380/discussions/0/451852225141685452/#c365163686049333645

RlndVt commented 6 years ago

@kisak-valve On what you mentioned, what kind of support do AMD-gpu's (using mesa) have?

alexmaras commented 6 years ago

All @kisak-valve was saying is that this issue is not specific to the rx480 as the title says.

All AMD GPUs on mesa use VA-API for hardware encoding and steam doesn't support VA-API for encoding at the moment.

@plagman should there perhaps be a seperate issue created to feature request VA-API encoding support?

RlndVt commented 6 years ago

I asked because there is also vdpau encoding, and maybe that is supported.

I do agree on creating a separate, or rather renaming this issue, specifically for VA-API.

edenist commented 6 years ago

Has there been any update on this issue recently?

That is, are we close to being able to use hardware encoding on AMD hardware yet?

HorstBaerbel commented 6 years ago

I'm trying to get hardware encoding on a Ryzen 2200G under Ubuntu 18.04 with the 4.16.12+ kernel from here and MESA drivers from here. I installed the necessary :i386 packages, but only have stuttering software encoding. vainfo tells me VA-API 1.1 is installed and H264 Main/High are available... Anything I could try?

kparal commented 6 years ago

@HorstBaerbel You might want to read the ticket more thoroughly, particularly https://github.com/ValveSoftware/steam-for-linux/issues/4890#issuecomment-362106453 . All AMD GPU owners (that includes Ryzen+Vega combo) are currently out of luck, until Steam devs implement support for them.

GitThisBugOff commented 6 years ago

This is really annoying honestly. I just finished setting up my streaming network and this encode issue has been a pain in the butt.

OvermindDL1 commented 6 years ago

Same issue, was testing streaming and noticed the substantial CPU usage, looked in to it and no hardware encoding was being performed on a Vega card, which was a bit wtf'ery, then found this issue. Why on earth would a proprietary useless one like NVENC be built in but the linux standard(s?) VA-API not being supported is a bit astounding... >.>

edenist commented 6 years ago

Yup, it's definitely a glaring outstanding feature in an otherwise great offering. It would be great to see some progress in this area. I'm sure there are many of us AMd users in the community who would be glad to help out.

HorstBaerbel commented 6 years ago

@karpal You might be right, but what confused me is that VA-API is already being used for hardware decode (on my Laptop with an Intel HD 620 iGPU though), so having VA-API support for encoding too only seemed logical... The issue is a year old and probably relevant much longer already. If the client (sans the DRM/protection parts) would be open-source, somebody would have fixed it already. But using Github to open a bug tracker without any source in it feels a bit half-hearted to me anyway...

Btw: Is it possible to render games on one GPU and use an extra (e.g. cheap Nvidia) GPU for encoding?

edenist commented 6 years ago

Btw: Is it possible to render games on one GPU and use an extra (e.g. cheap Nvidia) GPU for encoding?

Hmm, this is an interesting idea. Some searching online shows that it is somewhat doable with an AMD primary, then adding an nvidia card and installing the drivers with the --no-opengl-files option which should make sure it isn't overwriting anything display related. That said, this info is generally for people doing compute-type work. We would have to check if this would install NVENC and make it usable.

It then depends on how steam detects encoding options. It all might be for nothing if it only checks the current display GPU then falls back to software.

I don't have any nvidia GPU available at the moment, but I'll poke around on ebay etc to see if I can find something for cheap.

HorstBaerbel commented 6 years ago

Sounds good! Searching Wikipedia tells me that all Nvidia chips from the Kepler (GKxxx) generation on should support NVENC. These are used in the Geforce 600 and Geforce 700 series. In theory a cheap Kepler GT 630/730 should thus suffice, but be aware that there are Fermi GT 630/730 models too (wtf actually)! Getting a GT 740 or GTX 650/750 might actually be the safer bet as there seem to be no Fermi versions of them. Will try to get my hands on a GT 630 (hopefully Kepler) card next week and will try this out too.

ardje commented 6 years ago

But that means the image must go through the PCIe bus for each frame?

edenist commented 6 years ago

Yeah the way they re-branding of mid and low-end GPUs is pretty frustrating [AMD do it as well]. Interestingly, it appears that the GT 710 is an actual Kepler core and is still available in many stores brand new for very cheap.

But that means the image must go through the PCIe bus for each frame?

Yep, that's my concern as well. I don't know enough about how GPU encoding takes place. How does NVENC perform perform the encoding? Does the encoding take place with the data directly from the frame buffer [or, from somewhere on the same graphics card]?. If so, we're going to be sweet out of luck.

HorstBaerbel commented 6 years ago

But that means the image must go through the PCIe bus for each frame?

I know what you mean: (GPU->RAM->GPU->RAM->CPU->Network) instead of GPU->RAM->CPU->Network. Ideally DMA should take care of that, but tbh I have no idea how this works internally.

Does the encoding take place with the data directly from the frame buffer [or, from somewhere on the same graphics card]?. If so, we're going to be sweet out of luck.

Well, all the GPU drivers/software allow for some form of hardware-accelerated transcoding through the driver/software. So encoding must be possible w/o having data "in the framebuffer" / on the display (supposedly it is much cheaper to encode what's already in VRAM though, s.a.). Where the driver / card stores inter-frame information etc. for encoding I have no idea.

I guess we need to try it or Valve to enable VA-API for AMD. Whatever happens first... ;P

OvermindDL1 commented 6 years ago

I'm not actually sure DMA works between PCI-E nodes? Really though, VA-API should be used as it should support everything now (not just AMD but also Intel, some add-in cards, and it 'should' support nvidia as well depending on their driver quality, which is questionable as of late).

mvallerie commented 6 years ago

+1 for VA-API support for encoding. My CPU would definitely enjoy this.

HorstBaerbel commented 6 years ago

The GT 630 I got was a Fermi version so no testing atm :(

parkerlreed commented 6 years ago

Would love to see VAAPI support. As mentioned this would benefit more than just AMD.

parkerlreed commented 6 years ago

Any update on this? This is sorely needed as the software encoding eats a considerable amount of CPU even on a higher end machine.

screenshot_20180802_125859

Juppstein commented 6 years ago

Same here. With the introduction AMD Raven Ridge we have a perfect in-home streaming client platform but without the proper hardware support on the Steam side it just sits there using software encoding. The APU in my living room machine would like to have something to chew on, properly :)

lx0003 commented 6 years ago

VAAPI support +1

seijikun commented 6 years ago

If VA-API isn't supported at all, Steam does not use hardware encoding with Intel graphics cards either, does it?

OvermindDL1 commented 6 years ago

If VA-API isn't supported at all, Steam does not use hardware encoding with Intel graphics cards either, does it?

Correct. Steam only implements the proprietary nVidia protocol instead of the openly supported (by nVidia as well) protocol.

ghost commented 6 years ago

Can we please get a response from Valve on this?

Is hardware encoding going to be supported on Linux for AMD users or not?

@kisak-valve

ghost commented 6 years ago

AMF (h264) now on Linux via Vulkan: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/releases

timknab commented 6 years ago

AMF (h264) now on Linux via Vulkan: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/releases

Requires Pro stack though... https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/130#issuecomment-419309783

parkerlreed commented 6 years ago

@timknab So close yet so far away :disappointed: (That's my issue)

timknab commented 6 years ago

@timknab So close yet so far away 😞 (That's my issue)

Yeah, on Arch here too. Not sure the Pro stack is worth the effort/frustration, hopefully someone can get it working on the open driver or VA-API gets implemented soon.

OvermindDL1 commented 6 years ago

I thought the Pro stack had its development mostly halted and all new features and development were going into the open source amdgpu driver now? Why would they require the pro driver?!

mvallerie commented 6 years ago

@kisak-valve Any news on this ?

jjardon commented 5 years ago

I guess this is a duplicate of https://github.com/ValveSoftware/steam-for-linux/issues/4119 and can be resolved in the same way?

See comment at https://github.com/ValveSoftware/steam-for-linux/issues/4119#issuecomment-370708401 : http://voltaicforge.com/linux/steam-vaapi-fix-linux/

ghost commented 5 years ago

This isn't a duplicate of #4119 - That's hardware decoding. This is about hardware encoding. Currently unavailable because amdgpu lacks the driver support to do it. The pro stack has not long released AMF support via Vulkan, still unsupporterd by Steam and nothing yet for the open source driver. Hopefully AMF encoding will be made available to amdgpu in due course.

seijikun commented 5 years ago

@Holston5 What exactly is unavailable because of missing support in amdgpu? The start post even mentions that hardware encoding is supported since at least March 2017. In fact, I am actively making use of it with libva and gstreamer on my AMD R9 290 (with amdgpu).

ghost commented 5 years ago

@sejikun Are you absolutley sure? I have a 380 and like many others the hardware encoding tickbox in steam does nothing. Encoding is still done in software. In FFMPEG Our cards are supposed to have vaapi support, but it doesn't work because b-frames are not supported in the driver. You can test this using the ffmpeg snap package ffmpeg -vaapi_device /dev/dri/renderD128 -i input.mp4 -vf 'format=nv12,hwupload' -c:v h264_vaapi -b:v 5M ~/output.mp4

seijikun commented 5 years ago

@Holston5 Well that the hardware tickbox in Steam does nothing is to be expected. This is what this bug is all about: Valve not making use of vaapi in the first place. But the support from the driver-side is there. Valve only needs to use the API.

FFMpeg never worked for me with vaapi. Neither on AMD nor Intel graphics cards. With gstreamer however, I am able to encode HEVC in FullHD good quality with negligible CPU-usage and something in between of 30 to 60fps on a new (mobile) Vega 8 - and h264 with my R9 290, so I'm pretty sure it works.

Here is the cli I use (captures a FullHD video from the desktop and encodes it to h264):

gst-launch-1.0 -ev ximagesrc use-damage=0 endx=1919 endy=1079 ! video/x-raw,framerate=60/1 ! videoconvert ! video/x-raw,format=NV12 ! vaapih264enc quality-level=3 rate-control=2 ! "video/x-h264,profile=baseline,stream-format=byte-stream,framerate=60/1" ! h264parse ! mp4mux ! filesink location=test.mp4

But you indeed are right, B-Frames seem to be not supported by the card-firmware that AMD made available, even though the hardware should support it since VCE2.0.

Inspecting the resulting file per ffprobe -show_frames /tmp/test.mp4 | grep pict_type from the cli above shows that there are no b-frames. But do we need B-Frames for Steam streaming? ffmpeg can properly display the file that I created with gstreamer, so the receiving end should be no problem.

ghost commented 5 years ago

@seijikun this is invaluable information, thank you

timknab commented 5 years ago

@seijikun this is invaluable information, thank you

@Holston5

Is there any way to use this information to enable hardware encoding in Steam with an AMD card right now?

ghost commented 5 years ago

@timknab Unfortunately not

Mushoz commented 5 years ago

Has there been any news on this front? Would love to be able to use hardware encoding, especially since the API to do so is already there, ready to be used :)

tullo-x86 commented 5 years ago

But do we need B-Frames for Steam streaming?

No.

Not only are they unnecessary, but because they depend on both the previous and next I/P frames, B-frames add both latency and encoder/decoder complexity. Thus, when low latency is desired, B-frames are typically not used.