[Bug 91322] Usage of 'gallium' vaapi driver crashes radeon with inability to reset itself and scary pictures as if card has burned out

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91322

--- Comment #11 from Sergey Kondakov <virtuousfox at gmail.com> ---
(In reply to Christian König from comment #10)
> Well first of all try to avoid the VDPAU wrapper for VA-API or the VA-API
> backend for VDPAU. Those transition layers seem to have the tendency to add
> quite a bit of instability.

It would be easier if there was only one damn standard for GPU decoding. I can
do this for myself but I'm also would like to make a livecd where it works to
some degree automatically. LIBVA_DRIVER_NAME=gallium + VDPAU_DRIVER=va_gl would
solve that perfectly. Or work around the fact that those libs need to learn
autodetect appropriate implementation and there has to be only one of them or
one has to use a wrapper.

And don't get me started on what I had to do to make gst-omx loading with mesa
ST. Still haven't tested that. But no apps use it anyway.

> If you can try to use the native VDPAU implementation. We only did the
> VA-API implementation as a drop in replacement when the user has no other
> choice than to use VA-API.
> 
> So can you reproduce the issues with VDPAU as well, or is that limited to
> VA-API only?

The crash ? No. No crash or X hang on pure vdpau=r600 BUT it's quite useless
anyway since it always only shows the slideshow, in player's stats it shows no
more than ~10 frames (when it's ~150 on CPU) but on screen it looks more like
one per second.

And driver dying like still can't be appropriate.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150714/e33004f7/attachment.html>