| Summary: | segfault in radeonsi HEVC hardware decoding with yuv420p10le | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Pierre Ossman <pierre-bugzilla> |
| Component: | Drivers/Gallium/radeonsi | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED FIXED | QA Contact: | Default DRI bug account <dri-devel> |
| Severity: | normal | ||
| Priority: | medium | CC: | boyuan.zhang, irherder, patrick.oppenlander, shallowaloe |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | gdb bt full | ||
|
Description
Pierre Ossman
2019-05-17 19:48:15 UTC
Created attachment 144290 [details]
gdb bt full
A backtrace of the crash from gdb.
It looks like the allocation filed, but then either kodi or the driver went ahead and tried to clear the buffer anyway.
I think I've spotted a difference. The crashing files are all yuv420p10le, whilst everything else is in yuv420. Hope this helps. I found a lower resolution yuv420p10le video, and it crashes the same way. So it seems the pixel format is the key issue here, not the resolution. As a workaround, is it possible to configure VA-API to refuse to handle this specific format? It would be nice to have to disable hardware acceleration entirely. Hi, I believe I am experiencing the same issue, what can I do to help fix it? I can't reproduce it here, but maybe my test file (from https://github.com/mpv-player/mpv/issues/4736#issuecomment-333505294) isn't good to trigger the bug. Does the issue occur with the file above? And could you test with a different player? The sample provided in the post above is not triggering the crash. However a sample was provided to me that reliably crashes. https://drive.google.com/open?id=1bDhF6U5ccW-K1G63fl1qnO-98kopMJyw ryzen 2400g linux 5.1.10 mesa 19.1.0 ffmpeg 4.0.3 libva 2.5.0.pre1 (from git) kodi 19 (from git) I have a stacktrace but it's quite useless, if needed I could rebuild all the packages with debug info and reproduce. I don't have another player on the affected system atm. I believe this file is also triggering the crash condition. http://www.users.on.net/~ostickley/snip.mkv Thanks, I could reproduce on a Raven setup using the files from comment 7 and 8. The driver fails when trying to allocate a buffer for this video with a ENOMEM error (the requested size is 3 GB). (In reply to Pierre-Eric Pelloux-Prayer from comment #9) > The driver fails when trying to allocate a buffer for this video with a > ENOMEM error (the requested size is 3 GB). Well that strongly sounds like we miscalculated the necessary size somewhere. (In reply to Christian König from comment #10) > (In reply to Pierre-Eric Pelloux-Prayer from comment #9) > > The driver fails when trying to allocate a buffer for this video with a > > ENOMEM error (the requested size is 3 GB). > > Well that strongly sounds like we miscalculated the necessary size somewhere. Indeed. The size is computed by the `calc_ctx_size_h265_main10()` function. I'm not familiar enough with hevc to fix it though (but the calculation seems to overflow because context_buffer_size_per_ctb_row is 1GB and is multiplied by max_references (= 23) and the result is stored in an unsigned int). Can you try the branch from https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1154 and report if it fixes the issue for you? Applied the PR mentioned in 12 as a patch on top of the 19.1.0 tarball release. All the crashy samples I have now play perfectly. All the good media I have continues playing perfectly. Huge thanks for the quick fix. Is there any reason the fix isn't merged yet? The fix has been merged today (https://gitlab.freedesktop.org/mesa/mesa/commit/c81c784a4a05f8a957a649d73c8194247de47b56). And the fix is also included in Mesa 19.1.2 release. |
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.