Update on Vulkan video decoding vith open-source AMD driver RADV | Hacker News Reader

Update on Vulkan video decoding vith open-source AMD driver RADV

airlied.blogspot.com

77 pointsjlpcsl28 comments

Mad props to the dev(s) working on this, you're doing God's work mate.

I feel bummed by this whole Linux 'we-removed-codecs' situation, as AMD users were the only ones to feel this axing, despite the community hammering how they're the best for Linux compatibility, and ironically, Intel and Nvidia users were not affected by this decision.

I'm out of the loop, where can I find background information?

should be this I believe: https://lwn.net/Articles/910978/

[Ed.] Somewhat reminiscent of the crypto export restrictions around the millennium — with software patents being invalid in the EU (and a bunch of other jurisdictions), nothing would hinder the inclusion of these features in software distributed there...

[Ed. 2] Really reminiscent… it's only few jurisdictions where software patents are valid to a large degree - I found only the US, South Korea, and Armenia. Most other countries have significant hurdles or outright do not accept software patents.

> with software patents being invalid in the EU (and a bunch of other jurisdictions), nothing would hinder the inclusion of these features in software distributed there

I know the EU supposedly bans software patents, but looking at the patent pool for H.265, there's an awful lot of EU patents in there: https://www.mpegla.com/wp-content/uploads/hevc-att1.pdf.

Yeah, the problem in the EU is that they are lax in checks during the patent grant process and you have to sue to invalidate those patents later, even though they never should have been granted :(

https://linuxiac.com/fedora-and-opensuse-are-dropping-suppor...

It is only affecting Fedora and openSuse. Not affected are Arch, Gentoo, Ubuntu and Debian.

     * The hardware-acceleration is within the hardware and not in software - that is why it is named *hardware acceleration*. Fedoras decision doesn't make sense.
     * In Europe you cannot patent software - because you cannot patent logic. Sometimes software-patents are granted because the patent system is dysfunctional but these patents get revoked when challenged.
     * I doubt you can even defend a "software-patent" in America if challenged.
     * RedHat is weakening its position of Fedora (and of Linux) historically by similar decisions. Fedora is working well on desktops and laptops. But it is not acceptable for end-users to add extra repositories from RPMFUSION to get basic features working. The success of Canonicals Ubuntu is building up on this.
    * They're not removing it for Fedora <= 36. Removing features is evil. Ff Fedora is certain about their point-of-view they had to remove it, too?

Bonus - Qualcomm tries to attack AV1:

https://news.ycombinator.com/item?id=33638975

I think someone within the AOM needs to tell Qualcomm in polite words that another decade of missing hardware-acceleration and patent-trolling is not acceptable.

If you're worried about software-patents. I recommend moving the legal domicile and hosting servers to Europe. I'm sorry America but your mistake. The original intent of the patent system is proper documentation for the public. Instead it is used for hindering other upon improving existing ideas for decades. And lawsuits.

PS: Fedora is working excellent on laptops on desktops. While I prefer Arch personally, I do install Fedora on every computer of a "normal" person which is not within IT. It just works. Fedora is doing a good. But only if I add RPMFUSION first.

Canonical is weakening their position in the Linux world with snaps.

Fedora's foundations and technology are the best. I hate the RPMFusion situation, don't get me wrong, but it's the cleanest, most solid and best distro out there.

Canonical?

    * Unity - Failed against GNOME and Gtk
    * Mir - Failed against Wayland
    * Upstart - Failed against Systemd
    * Snap - Currently in fight against Flatpak

Canonical's help and cooperation is appreciated. Since they returned to GNOME a lot of things got improved for all! I've the impression Canonical is trying to push a always an own solution which is either inferior, not backed by community or follows a dark-pattern (Snap server is closed-source). I'm afraid Ubuntu-Phone could've been a success if they searched cooperation with Red Hat, Purism or Jolla. Again...no :(

Removing support for those particular codecs isn't the end of the world. YouTube, Disney, Netflix, Prime Video (ie. the largest video streaming sites) all use open codecs and thus are unaffected by Fedora/Suse's decision.

I'm afraid all of them use H264 or H265 as baseline, AV1 only when advertised. AV1 is only available hardware-accelerated on the newest devices (AMD >= RNDA2, Intel >= Xe, Nvidia >= Ampere) from 2020. Googles Pixel 6 is one of the first phones with AV1. Software support requires the CPU to do the work and drains the battery.

Don't know about the others, but at least YouTube also uses VP9, which is open and capable of being hardware decoded by most devices.

I afraid this is optimistic. Hardware support for VP9 is only available from AMD Polaris or Intel KabyLake. I think Apple started supporting VP9 only in 2020, likely excluding holder hardware. Youtube ships here VP9 and my Linux is able to accelerate it luckily on a T14. Not on my X220 ;)

Keep in mind implementing ASICs need a way more time and a way more till broad support has reached customers. Systems with Sandy Bridge or even earlier (like ThinkPad X201) are working fine and being used. Long working reliable hardware is a good thing.

Streaming (select best codec) can adapt quicker than video-chat (common codec). And so called "Smart TVs" will not receive updates at all?

YouTube and Netflix use VP9...

For now, but the push to AV! is near.

The hardware codec support removal is a bone headed decision. The first sale doctrine (among other things) says that if you sell a patented device, you are implicitly selling a transferrable patent license that allows use of that one physical device.

So, there are two possibilities for patent infringement:

1) AMD licensed a patent that allows them to write software that accesses hardware capabilities using software drivers. This is already ludicrous, but the US patent system is in play. Furthermore, the third party patent holder is asserting that AMD's license only applies to Windows drivers.

2) AMD's hardware violates a third party patent.

In both cases, this is AMD's problem, not the Linux distribution's. Also, no one is claiming either of the above things have happened.

(Not a lawyer, but this is basic IP law.)

It would be AMD's problem, but US patient law lets them sue anybody downstream too. Another failing.

Maybe the issue doesn't have to do with winning or losing the case, but with being sued at all (which implies some defense costs, of course)

Why is it legal to ship it in intel-media-driver and not in Mesa?

Just a side note that at least openSUSE has community-backed solutions for distributing the codecs anyway (long live OBS). This is not optimal long term solution but it works(tm) for at least AMD.

(Background: I'm daily driving openSUSE tumbleweed and had to deal with it fairly recently)

I still have yet to get video encoding ever working on fedora with chromium, even with the mesa driver including closed codecs. It just never works, it always uses the CPU for some reason.

And thats with AMD, Nvidia is a lost cause.

What's this doing? Is it software-decoding-on-GPU using GPU compute or is it using the hw video codec functionality through the Vulkan API?

It's an API to access the HW decoders and encoders on the GPU or on some other hardware.

What's going on in radv?

Valve did kick out llvm with aco (which is faaaaaar less worse than the former, I wish it was plain and simple C).

But now, I see some stuff (KHR "acceleration structure") pulling that horrible glslang compiler from khronos into the SDK.

If hardware specific shaders are to be required for some vulkan fancy APIs where no silicium blocks is available, they should be written in GCN/RDNA|SPIR-V code with plain and simple C coded assembler.

Can someone explain to me what this is, like I’m five years old?

Vulkan adds new features by first adding an extension for the feature.

Then a later version of "mainline Vulkan" will upgrade those optional extensions to include them in the non-optional API. Even then, the feature underneath it is often optional, but the API to support it is built in, leaving it up to the app to check some feature bits before using it.

Specifically the vulkan extensions that Dave Airlie has implemented for AMD GPUs from TONGA to NAVI2x are:

   VK_KHR_video_queue
   VK_KHR_video_decode_queue
   VK_EXT_video_decode_h264
   VK_EXT_video_decode_h265

But he notes that the implementation work isn't done. It's just getting started.

Can someone explain to me what this is, like I’m five years old?

Programmers have many secret languages they talk to computers with. This is about a secret language that allows computers to make pretty things on your screen, being used to put video on there too.

It's a someone's computer program that can make the battery last longer when watching videos, when it they finish it.

Reply on news.ycombinator.com