Comment # 11
on bug 91322
from Sergey Kondakov
(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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
