The memory leaks in Source games and xvba playback exist since 13.8 beta was first released. Im pretty sure they know about them as it affects Steam's most prevalent 3d engine. What im surprised about is that they released an official driver that has these big bugs.
Originally Posted by deri
Correct me if I'm wrong, but I think steam and steam games related bugs/issues should be reported here: http://devgurus.amd.com/community/steam-linux
However, as a reporter myself I don't see too much activity there...
I have dota and steam for linux gits open I see quite much activity on the dota2. Somebody comments on your issues quite fast. The valve forum for linux has become quite silent place. It feels like that there are less than 100 people reading and writing things.
That does not help much. The vsync bug (100% load on one core) was in the driver since October 2012 :-) We then worked actively with AMD devs, via beta mailinglist and whatever, to get that solved - it was solved with 13.6 - and reintroduced in 13.8beta with a nice additional memleak :-)
I just gave up. I won't install a catalyst anymore. XVBA development is _stopped_ we did not thing in the code for more than 6 months, as we get no new SDK and users blame us for memleak and bad drivers.
I will go with the free drivers for now. Xbmc is not yet ready on OSS UVD - but we are working on a solution - especially the really helpful AMD OSS guys put a lot of effort into their driver / mesa development to get the performance issues we currently have, fixed.
XVBA will be obsolete.
Those of you having issues with Unity reverting to 2D:
1. Are you on 64bit?
2. Have you installed the drivers from a tty with X.org shut down? (sudo service lightdm stop)
3. Have you issued "sudo rm /etc/ati/amdpscdb" before rebooting?
Originally Posted by PsynoKhi0
3. stopped lightdm, rm, restart without change.
Is any other native xvba speaking player out there for catalyst users? Or no more hw decoding for them?
Originally Posted by fritsch
Also, vdpau works quite well with mplayer and gnome-mplayer (but doesnt get along with smplayer) - why doesnt it with xbmc?
Short answer: xbmc is OpenGL, fully 3D
There is no way to get the surfaces back to OpenGL, than via pixmaps. This was fast enough for ION-1s and ION-2s, but it is not for the radeons.
Xbmc has a second way to handle that problem. Proprietary nvidia implements glinterop, which is currently also adapted for mesa but not there yet.
Basically playing a video in mplayer is far more easy than doing it in an OpenGL App, when there is no real api call to get the rendering target transfered (fast).
XVBA will die. We were the one and only application that implemented it. There is nothing else in the OSS world that uses it - despite the 2 years old not maintained anymore xvba-va-driver.
It's very hard NOT to see memory leaks with L4D2 and other source engine games - maybe the dev boxes just have too much ram compared to home users that it does not crash so fast - you can see the memory leak with htop easyly. It is more or less impossible that one of those fglrx devs plays with AMD gfx cards with Steam/Linux. Tell me one...