AMD GPUOpen Working On A New "gpurt" Open-Source Project

[Guest]

Not sure about "3" unless you are talking about the different generations of back ends ? What are the three you are thinking about ?

I may be using the wrong term with driver, but the three things I'm referencing are Clover, AMDGPU-PRO, and ROCm. My understanding is:

• Clover is open-source and part of Mesa; has the worst OpenCL support
• AMDGPU-PRO is proprietary and from AMD
• ROCm is open-source from AMD only for newer GPUs and platforms

Getting either AMDGPU-PRO or ROCm installed has largely-varying methods depending on the distro, whereas Clover just-exists like amdgpu. I believe if Clover had at least OpenCL 2.0 support it would be mostly usable.

[bridgman]

OK, thanks. We haven't touched Clover for almost a decade - we could delete the code but I don't think that would be appreciated.

We run exactly the same OpenCL code paths in AMDGPU-PRO and ROCm for Vega and onward - I believe it's even the same install packages these days. As far as I know all of that code is open source, ie there is no proprietary OpenCL any more.

Wherever possible we release ROCm and AMDGPU-PRO stacks together so that they can not only come from a common codeline but from the same commits as well.

[Calinou]

Can I hope for an "OpenEncoding" someday?

I mean I try with VAAPI, but the thing simply has problems. A refresher/new code may really be good...

I'd like to see more efforts around providing video decoders based on Vulkan compute, so they can be made easier to work in various applications (especially game engines). I can understand patents make this difficult for H.264 and H.265 though.

[Quackdoc]

OK, thanks. We haven't touched Clover for almost a decade - we could delete the code but I don't think that would be appreciated.

Have you guys been keeping an eye on rusticl? it seems like it could grow into a suitable replacement for clover, and would love to see some amd work plumbed up for it

[Mahboi]

Last time I tried support for accelerated encoding worked with amdgpu, at least when using ffmpeg. Couldn't get it to work with OBS, which I'm guessing you're using.

Edit: I guess it depends on your card too. Fiji and Tonga had problems that will never get fixed. My card was a Polaris.

Actually my experience was with hardware decoding with a Chromium (Vivaldi to be specific).

My specs are very recent (5600x and rx 6600), and I went through quite a lot of vines to get it to work.

The results were frankly not up to snuff: my CPU went from 5-10% usage down to 3-8%, and my graphics card had its memory constantly running at 100% speed in exchange for that. Arguably this is a driver problem, but still, it kept pushing the generally passive cooling into active for the gfx. ASUS set it to start spinning the fans when 60°C are reached, so it kept spinning on then off after 2 minutes, then restarting after 8 or so minutes.

But the problem was that I was having serious issues with Twitch hw decoding: certain streams would just have severe stops on a frame for an entire 3 to 5 seconds, and that was accompanied by the sound too. Once I turned off hw accel, it all went back to normal. It wasn't with every stream, but even just one, for this kind of tiny gain and fan spinning annoyance, wasn't even worth keeping the thing.

I have the goal to eventually stream on Twitch myself again someday, I'll see how hw accel runs on OBS then, but considering your post, I'm not expecting anything except to jump back to CPU quickly. It's sad that AMD is heavily shilled, and for good reason, in the Linux world, but at the same time their drivers and general ecosystem is plainly not as reliable as Nvidia's MyWare. Nvenc disappoints nobody, but VAAPI truly doesn't seem to be anything but an afterthought.

Once RDNA3 starts damaging Nvidia's dominance, I hope AMD will have at least some resources to pay to the extras like a solid encoding/decoding stack. It's needed.

[agd5f]

Have you guys been keeping an eye on rusticl? it seems like it could grow into a suitable replacement for clover, and would love to see some amd work plumbed up for it

Whether it is rusticl or clover, it would ideally use the KFD/ROCr interfaces rather the the graphics interfaces to submit work to the GPU. Work has to complete in finite time on the graphics side which makes supporting long running shaders impossible. The OpenCL implementation that is used in ROCm and the packaged drivers does make use of KFD.

[stalkerg]

Whether it is rusticl or clover, it would ideally use the KFD/ROCr interfaces rather the the graphics interfaces to submit work to the GPU.

is it so a big issue for Mesa?

[agd5f]

is it so a big issue for Mesa?

Not for gfx or multimedia. The expectation for gfx is that the work completes in finite time. E.g., you want to work to complete in time to display the frame. For compute you may have tasks which run for hours or days or longer.

[Developer12]

I wouldn't be surprised about realtime interest. It was a major sticking point with nvidia drivers under their proprietary driver. Companies wanted to use the same GPUs along with CUDA in cars, but plumbing in support for RT kernels with those drivers was basically impossible. Too invasive for a proprietary driver you actually intend to sell.

With that no longer being a barrier for nvidia realtime development? AMD might be trying to get ahead while they still have some open-source advantage.

[AndyChow]

But the problem was that I was having serious issues with Twitch hw decoding: certain streams would just have severe stops on a frame for an entire 3 to 5 seconds, and that was accompanied by the sound too. Once I turned off hw accel, it all went back to normal. It wasn't with every stream, but even just one, for this kind of tiny gain and fan spinning annoyance, wasn't even worth keeping the thing.

I have the goal to eventually stream on Twitch myself again someday, I'll see how hw accel runs on OBS then, but considering your post, I'm not expecting anything except to jump back to CPU quickly. It's sad that AMD is heavily shilled, and for good reason, in the Linux world, but at the same time their drivers and general ecosystem is plainly not as reliable as Nvidia's MyWare. Nvenc disappoints nobody, but VAAPI truly doesn't seem to be anything but an afterthought.

Once RDNA3 starts damaging Nvidia's dominance, I hope AMD will have at least some resources to pay to the extras like a solid encoding/decoding stack. It's needed.

I think you mean Twitch hardware encoding? If streaming, you are encoding, not decoding.

My guess is that for games, or streaming, you are better off with windows. OBS used to crash under linux when I would add certain sources, or choose certain areas, or a lot of things. It was almost "superstitious", in the sense I could trick it from crashing by doing certain things like modifying a scene, then modifying back, then it wouldn't crash. But if I loaded the scene right away, it would crash. Under Windows, everything works, every input source seems compatible. But windows is pretty useless outside gaming and recording yourself gaming.

It's not that it doesn't work with linux, since I was able to do just about everything with ffmpeg directly from bash scripts. But complicated programs like OBS (and I'm guessing Twitch, but I don't really know anything about Twitch) really treat linux as a 3rd class citizen. Heck, it's the way the market's always been.

Nvidia's not the Eldorado either. Plenty of complaint from the Wayland club. Actually, Linux really, really sucks when it comes to graphics. It's really not the fault of the people working on that side, it's just that the problem is very complex. But if you're not afraid of writing scripts, ffmpeg has always worked out of the box, when fed the correct switches. VAAPI did work, so does VDPAU on the Radeon RX480 with the mesa-vdpau translation layer, but I think it only supported X264.

In any case, hardware accelerated encoding always results in an inferior product, so keep that in mind also.