Bug 103274

Summary:	BRW allocates too much heap memory
Product:	Mesa	Reporter:	Fabian Vogt <fvogt>
Component:	Drivers/DRI/i965	Assignee:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Status:	RESOLVED FIXED	QA Contact:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity:	normal
Priority:	medium	CC:	sergii.romantsov
Version:	git
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Screenshot of leaking path in heaptrack

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.