Major AMD Catalyst Linux Update Expected Next Week

[xeekei]

I don't expect AMD to contribute to libva itself. I don't even think they really bothered with contributing to the xvba-vaapi wrapper. They just let Gwenole Beauchesne of Splitted Desktop try to hack it together, which he did to some extent before concluding that libxvba was buggy and moving on to working on libva as an Intel employee.

Is it cynism clouding your judgment, or do you geniuinely not believe that AMD could benefit from contributing? Not picking a fight, just trying to get where you're coming from.

[xeekei]

Is it cynism clouding your judgment, or do you geniuinely not believe that AMD could benefit from contributing? Not picking a fight, just trying to get where you're coming from.

Cynicism, I mean of course.

[DanL]

Is it cynicism clouding your judgment, or do you genuinely not believe that AMD could benefit from contributing? Not picking a fight, just trying to get where you're coming from.

I said that I didn't expect them to contribute to libva based on past behavior with xvba, regardless of whether they (or anyone) could benefit from upstream contributions. I have no idea whether upstream changes are even needed to get VA-API working on Catalyst. Actually, one would hope that libva is mature and vendor-agnostic enough where it doesn't need a bunch of hacks to work with Catalyst (similar to open drivers on libvdpau).

So yes, I'm a bit cynical that AMD is going to devote lots of resources to Linux-specific Catalyst features based on their past behavior. That doesn't mean I don't appreciate their getting rid of libxvba, even if I personally don't use Catalyst. It's a step in the right direction and I applaud the move.

[przemoli]

Cynicism, I mean of course.

It wouldn't be first time

AMD is manpower constrained, and You can see it all around. (They tryied to improved OpenCL, released impreved driver, went to work on Mantle, released some drivers there, - linux floss team - went to support this new unified kernel driver, oh! and HSA is still on the roadmap too!)

Its not 100% switching, but AMD seam to be moving people/teams/focuses a lot last two years.

Good news is, that its mostly new developments that nobody else work on. So go AMD!

(And floss team seam to be involved with HSA and unified model, but not much else, so they work on usual things without much surprise)

[by.peroux]

I'm very interrested in this distribution package thing. It could bring me back to fedora.

[fritsch]

Let's see what does not work this time: https://github.com/xbmc/xbmc/commit/...303a3386cbd565

After the great XVBA fuckup some years ago I really hope it will just work (TM) this time with VAAPI.

And what I really don't hope is, that they just "integrated" the old xvba-va-wrapper into fglrx without changing the GL issues it had.

[Nille]

@fritsch did you know if someone test the new va-api state tracker with older amd hardware with kodi already?

[nanonyme]

I'd personally expect opensource VAAPI support to be higher priority for them with amdgpu than proprietary

[fritsch]

@nille: No reports at all for now. Most likely the vaputSurface implementation will suck, we will see. kodi's implementation is multithreaded. One for the decoder, one for postprocessing and async render. So the surfaces are shared in those different states - for now I have not seen any wrapper that does not just segfault in that scenario :-) (which is the reason we only whitelist intel).

They should have chosen VDPAU ... i think they only used VAAPI cause of the "wrapper" was already there. Curious which libva version they implement and if we will see VPP.


We don't have any intention to implement workarounds to kodi for yet another fglrx api ... basically we were done with fglrx after the xvba times ... but with the linked patch AMD can test their code easily by adding a ppa - so no excuses then :-)

[Nille]

@nille: No reports at all for now. Most likely the vaputSurface implementation will suck, we will see. kodi's implementation is multithreaded. One for the decoder, one for postprocessing and async render. So the surfaces are shared in those different states - for now I have not seen any wrapper that does not just segfault in that scenario :-) (which is the reason we only whitelist intel).

With the new VA-API state Tracker?

And i don't care the fglrx the most time, only the FOSS-Driver