Originally posted by DanL
View Post
Announcement
Collapse
No announcement yet.
Major AMD Catalyst Linux Update Expected Next Week
Collapse
X
-
-
Originally posted by xeekei View PostIs 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.
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.
Comment
-
Originally posted by xeekei View PostCynicism, I mean of course.
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)
Comment
-
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.
Comment
-
@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 :-)
Comment
-
Originally posted by fritsch View Post@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).
And i don't care the fglrx the most time, only the FOSS-Driver
Comment
Comment