Bug 110602 - i965 miptree MCS aux_buf allocation failure with old kernels
Summary: i965 miptree MCS aux_buf allocation failure with old kernels
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: All Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Reported: 2019-05-03 14:17 UTC by Anssi Hannula
Modified: 2019-09-25 20:33 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

glxinfo (20.34 KB, text/plain)
2019-05-03 14:17 UTC, Anssi Hannula
Add MMAP_WC check before using MCS (2.55 KB, patch)
2019-05-03 14:17 UTC, Anssi Hannula
Details | Splinter Review
Testcase Qt C++ program (4.24 KB, text/plain)
2019-05-03 14:18 UTC, Anssi Hannula
Testcase apitrace (68.55 KB, application/octet-stream)
2019-05-03 14:18 UTC, Anssi Hannula
Fallback to non-raw mapping (1.07 KB, patch)
2019-05-06 08:42 UTC, Anssi Hannula
Details | Splinter Review

Description Anssi Hannula 2019-05-03 14:17:03 UTC
Created attachment 144147 [details]

intel_miptree_choose_aux_usage() selects ISL_AUX_USAGE_MCS if intel_miptree_supports_mcs() returns true.

This will cause callchain intel_miptree_alloc_aux() => intel_alloc_aux_buffer() => brw_bo_map(x,y,MAP_RAW|MAP_WRITE) => brw_bo_map_wc(), which checks bufmgr->has_mmap_wc and returns NULL on !bufmgr->has_mmap_wc. There is no fallback in brw_bo_map() for the MAP_RAW case.

This will cause intel_miptree_create() to fail which causes intel_miptree_create_for_renderbuffer() to fail.

I guess either either the miptree creation should be retried without MCS or intel_miptree_supports_mcs() should detect the missing mmap_wc support and return false.

Attached is a quick hack patch that adds mmap_wc check in intel_miptree_supports_mcs(), and it seems to fix the testcase I used (mesa-issue-qt3d.cc).
Without the patch the testcase either crashes (git master) or flashes rapidly (git master + two patches from bug #110601 to workaround the crashes).

The testcase mesa-issue-qt3d.cc is also attached, plus an apitrace and glxinfo with git master.

This was tested on a ValleyView Gen7 (8086:0f31) with kernel 3.10.35.
Comment 1 Anssi Hannula 2019-05-03 14:17:55 UTC
Created attachment 144148 [details] [review]
Add MMAP_WC check before using MCS
Comment 2 Anssi Hannula 2019-05-03 14:18:12 UTC
Created attachment 144149 [details]
Testcase Qt C++ program
Comment 3 Anssi Hannula 2019-05-03 14:18:29 UTC
Created attachment 144150 [details]
Testcase apitrace
Comment 4 Nanley Chery 2019-05-03 14:44:56 UTC
Hi Anssi,

I actually have a series that allows the GL drivers to fallback to not having compression if auxiliary surface allocation fails. Does this branch fix your issue? https://gitlab.freedesktop.org/nchery/mesa/tree/sent/refactor/aux-assign
Comment 5 Anssi Hannula 2019-05-03 15:15:18 UTC
Yes, it indeed does fix this bug, thanks.
Comment 6 Nanley Chery 2019-05-03 16:14:16 UTC
An better performing fix (and possibly the right fix) would involve falling back to a supported mapping. Though, I'm not sure if there would be anything blocking that solution.
Comment 7 Kenneth Graunke 2019-05-03 16:46:11 UTC
I think we can drop MAP_RAW if MMAP_WC isn't supported - using a tiled mapping is kind of weird, but we're just filling the whole buffer anyway.  We used to do it before 3b4f432d9bbdf86bb6e0e84c6053959aa3194daa.
Comment 8 Anssi Hannula 2019-05-06 08:42:29 UTC
Created attachment 144171 [details] [review]
Fallback to non-raw mapping

Indeed, the attached patch that simply fallbacks to non-MAP_RAW seems to also work, at least with my testcase.

The patch fallbacks to non-raw in all cases, no idea if that is wanted or just for MCS.
Comment 9 GitLab Migration User 2019-09-25 20:33:17 UTC
-- 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/1810.

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.