Bug 95545 - [amdgpu][tonga] mplayer -vo=gl:yuv=2 causes VM fault
Summary: [amdgpu][tonga] mplayer -vo=gl:yuv=2 causes VM fault
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-23 15:37 UTC by csaba.halasz
Modified: 2016-06-27 15:18 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
vm fault report (88.66 KB, text/plain)
2016-05-23 15:37 UTC, csaba.halasz
Details
dmesg output (3.01 KB, text/plain)
2016-05-23 15:38 UTC, csaba.halasz
Details
stderr (118.32 KB, text/plain)
2016-05-23 15:39 UTC, csaba.halasz
Details
apitrace (148.12 KB, application/octet-stream)
2016-05-23 15:39 UTC, csaba.halasz
Details

Description csaba.halasz 2016-05-23 15:37:35 UTC
Created attachment 123994 [details]
vm fault report

Running mplayer with -vo gl:yuv=x  with x>1 causes GPU VM fault.
yuv=0 is software rendering, that works fine.
yuv=1 uses GL_NV_register_combiners and that doesn't fault but the output is unusable.

The other values use fragment shaders, those are all broken.

Reportedly the apitrace works with older versions, mesa 11.2.2 and llvm 3.6.2.

kernel agd5f/drm-next-4.7 git 3b59c344ab6e2d00b0f4ad946024572618c87502
mesa git 65c2abf6fdd51b0a80a72caa0c52cf3f4578e743
llvm git ef1f2996c17c9b1480201239002b58851810e8fc
xf86-video-amdgpu git 60ced5026ebc34d9f32c7618430b6a7ef7c8eb4b
Xorg 1.18.0
mplayer svn r37870
gigabyte 380 (tonga)
Comment 1 csaba.halasz 2016-05-23 15:38:11 UTC
Created attachment 123995 [details]
dmesg output
Comment 2 csaba.halasz 2016-05-23 15:39:05 UTC
Created attachment 123996 [details]
stderr
Comment 3 csaba.halasz 2016-05-23 15:39:23 UTC
Created attachment 123997 [details]
apitrace
Comment 4 Andy Furniss 2016-05-23 22:44:06 UTC
Doesn't affect other players using gl.

But anyway, testing with mplayer -vo gl <file> bisect came up with -

commit 70934de00eb42ba6fc43d104875962dfb260a1b3
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Thu Apr 21 21:41:59 2016 +0200

    radeonsi: add new SDMA texture copy code
    
    This implements:
    - Linear-to-linear partial copies. (unaligned)
    - Tiled-to-linear and linear-to-tiled partial copies.
      (unaligned except 1-2 Bpp)
    - Tiled-to-tiled partial copies aligned to 8x8.
    
    v2: Extend the SDMA L2T VM fault workaround to T2L.
        - Same algorithm, just applied to T2L.
          (and using a 0-based address and surface.bo_size instead of buf->size)
Comment 5 Marek Olšák 2016-05-26 20:21:44 UTC
The problem is with the CE preamble which is sometimes skipped when it shouldn't be. SDMA IB submission somehow affects it. The workarounds are:
- disable SDMA (bad)
- disable CE preamble (not so bad)
- execute SDMA in a different amdgpu context (not tested, just an idea I'll try next)
Comment 6 Marek Olšák 2016-05-26 21:42:52 UTC
Using a difference context for SDMA doesn't help. Disabling the CE preamble seems to be the only solution.
Comment 7 Marek Olšák 2016-06-27 15:18:47 UTC
This seems to be fixed. Possible fix:

commit 54f755fa0fda14c578022767bcef2f27b2e89707
Author: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Date:   Mon Jun 6 22:36:35 2016 +0200

    radeonsi: Reinitialize all descriptors in CE preamble.


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.