Bug 103274 - BRW allocates too much heap memory
Summary: BRW allocates too much heap memory
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-14 14:38 UTC by Fabian Vogt
Modified: 2018-07-23 08:28 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Screenshot of leaking path in heaptrack (142.80 KB, image/png)
2017-10-14 19:48 UTC, Fabian Vogt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2017-10-14 14:38:10 UTC
With current mesa git it is not possible to play various 32bit games with wine, as the d3d hlsl to glsl translator generates many non-trivial shaders.
For unity games like "Ori and the blind forest", they just crash after the whole 4 GiB address space is exhausted and malloc cannot return any more space.
The vast majority of the allocation calls are caused by ralloc_size called from brw_* and other shader related functions.

As a workaround I built i965_dri.so from https://cgit.freedesktop.org/~jljusten/mesa/commit/?h=i965-shader-cache and I was able to run the game by letting it compile the shaders until it runs out of memory, repeated until the shader cache is sufficiently filled so that subsequent starts do not run out of memory anymore. Now the game uses barely more than 1GiB after startup. The ~/.cache/mesa directory contains 26MiB, which indicates (AFAICT) that some stage in the shader compilation process does not free its resources correctly.

So it's likely a memory leak somewhere, but I don't know how to debug that to provide more information.
Comment 1 Kenneth Graunke 2017-10-14 17:56:46 UTC
Are you able to reproduce this with apitrace?  (Presumably, you'd need to replay with a 32-bit version of glretrace...)
Comment 2 Fabian Vogt 2017-10-14 19:10:32 UTC
(In reply to Kenneth Graunke from comment #1)
> Are you able to reproduce this with apitrace?  (Presumably, you'd need to
> replay with a 32-bit version of glretrace...)

I can - with a 64 bit version as well, it just gets killed by the kernel on OOM instead of running out of memory (malloc returning NULL).
Comment 3 Fabian Vogt 2017-10-14 19:48:32 UTC
Created attachment 134844 [details]
Screenshot of leaking path in heaptrack

I ran glretrace with heaptrack to get a backtrace of the leaked malloc calls - I can upload the heaptrack output file if needed.
I'm not sure whether I can upload the apitrace output file due to copyright reasons.
Comment 4 Sergii Romantsov 2018-07-23 06:21:37 UTC
Hello, Fabian.
Could you, please, try with commit d219521379626ebf2bff63e4a9c2f92725b3926a or with master.
Some improvements were done.
Comment 5 Fabian Vogt 2018-07-23 08:28:29 UTC
(In reply to Sergii Romantsov from comment #4)
> Hello, Fabian.
> Could you, please, try with commit d219521379626ebf2bff63e4a9c2f92725b3926a
> or with master.
> Some improvements were done.

Seems to work here - it doesn't exceed 3GiB anymore.

However, loading the game takes really long now, but I can't really compare it as until now it wasn't possible to load it at all without shader caching.


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.