| Summary: | Usage of 'gallium' vaapi driver crashes radeon with inability to reset itself and scary pictures as if card has burned out | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Sergey Kondakov <virtuousfox> |
| Component: | Drivers/Gallium/r600 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED MOVED | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | major | ||
| Priority: | medium | ||
| Version: | 10.6 | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Xorg.0.log.old
dmesg-from-crash-on-flash-video-with-vaapi-gallium-#1 dmesg-from-crash-on-flash-video-with-vaapi-gallium-#2 dmesg-from-X-hang mpv-vdpau-via-va_gl=X-hang mpv-vaapi=slideshow mpv-vdpau=slideshow |
||
|
Description
Sergey Kondakov
2015-07-13 06:23:29 UTC
Please attach your full dmesg output. Can you also provide the application log from and options used to decode? Created attachment 117109 [details]
dmesg-from-crash-on-flash-video-with-vaapi-gallium-#1
Created attachment 117110 [details]
dmesg-from-crash-on-flash-video-with-vaapi-gallium-#2
Same situation as with the previous one but with new message at the end
Created attachment 117111 [details]
dmesg-from-X-hang
Not a crash but a hanging X. Happened while running mpv video player with va_gl->vdpau and not flash plugin as was in case of full crash.
Created attachment 117112 [details]
mpv-vdpau-via-va_gl=X-hang
Created attachment 117113 [details]
mpv-vaapi=slideshow
Using vaapi=gallium or vdpau=r600 results in pure slideshow but not crash this time around
Created attachment 117114 [details]
mpv-vdpau=slideshow
Using vaapi=gallium or vdpau=r600 results in pure slideshow but not crash this time around
(In reply to Alex Deucher from comment #1) > Please attach your full dmesg output. Can you also provide the application > log from and options used to decode? For some reason I couldn't reproduce the complete crash with a player this time but I've managed to consistently and immediately crash the driver with playing http://thedailyshow.cc.com/videos/vbp8i5/living-in-denali in the Firefox with chromium-pepper-flash-18.0.0.160 + freshplayerplugin-0.3.1 while its "enable_hwdec" option is set. All with LIBVA_DRIVER_NAME=gallium However, I also managed to hang X (picture is stuck but zapping combination works and brings the new one back) by running 'env LIBVA_DRIVER_NAME=gallium VDPAU_DRIVER=va_gl mpv -vo opengl --hwdec=vdpau' which needs https://github.com/i-rinat/libvdpau-va-gl from the creator of freshplayerplugin. Here's some logs. Ah, and I don't know if its normal or not and pertaining to that issue or not (maybe that confuses something else in the driver). But I can't seem to get vsync working. Earlier I used "EXAVsync" and that was that. But now even it doesn't help and I'm getting stuff like: Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 20074 frames in 5.0 seconds = 4014.652 FPS Doesn't work under both EXA and glamor. Don't quite know when it changed. It does work however with bleeding edge X stack + mesa 10.7~git and "TearFree" option but with it 1) clock speed and voltage are always on maximum 2) mpv/bomi are slowly desynchronizing audio and video 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. 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? (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. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/551. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.