Bug 32579 - i915 DRI driver consumes incredible amounts of memory when creating many small textures
Summary: i915 DRI driver consumes incredible amounts of memory when creating many smal...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: 7.9
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-22 09:57 UTC by Arthur Huillet
Modified: 2011-08-22 11:55 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Small OpenGL program that uploads lots of small textures (4.62 KB, text/plain)
2010-12-22 09:57 UTC, Arthur Huillet
Details
(untested) DRM patch to refuse tiling when it would artifically enlarge the texture (417 bytes, patch)
2011-01-04 14:11 UTC, Arthur Huillet
Details | Splinter Review
7.9 7.10 Disable texture tiling for textures < 1024x1024 (1.11 KB, patch)
2011-01-05 10:35 UTC, Arthur Huillet
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Arthur Huillet 2010-12-22 09:57:07 UTC
Created attachment 41374 [details]
Small OpenGL program that uploads lots of small textures

Hello,

I am attaching a small test case that shows the problem by uploading 1000 RGBA textures, size 64x64. The actual texture size in total is 15MB, but the driver eats up to 1GB of memory on my system.

This gets my OpenGL application a out-of-memory kill by the kernel after only a few minutes, since it uses a lot of small textures like this.

This used to work fine (200MB of textures uploaded -> about 200MB of memory usage) in Mesa 7.7.
Comment 1 Arthur Huillet 2010-12-22 09:57:26 UTC
By the way, this is my version string:

Vendor     : Tungsten Graphics, Inc
Renderer   : Mesa DRI Intel(R) 915GM GEM 20100330 DEVELOPMENT x86/MMX/SSE2
Version    : 1.4 Mesa 7.9
Comment 2 Chris Wilson 2010-12-23 01:26:01 UTC
You need a 2.6.38 kernel (or drm-next) + libdrm-2.4.23.

As you probably already realised using a texture atlas should also reduce the number of state changes required for the scene.
Comment 3 Arthur Huillet 2010-12-23 01:31:00 UTC
I'll confirm that the problem has been fixed in linux-next as soon as possible.

However the issue seems pretty serious because as far as I can tell, major distros such as Ubuntu 10.10 have the problem, and this seems to have the potential to impact a lot of OpenGL applications.

Perhaps something should be done for the fix to be included in 2.6.37?

Thanks for your time
Comment 4 Chris Wilson 2010-12-23 02:21:50 UTC
It's neither a stability fix nor is it trivial. The easiest workaround is to disable tiling by setting "texture_tiling = false" in driconf.
Comment 5 Arthur Huillet 2010-12-23 02:35:29 UTC
Thanks for the hint.

http://www.mail-archive.com/mesa-commit@lists.freedesktop.org/msg16414.html

Shouldn't that be reverted or at least be made to depend on the texture size? Wouldn't it suffice and be an acceptable solution?

My feeling is that the *default* behavior of an OpenGL driver should be not to trigger OOM-kills for no good reason.
Comment 6 Chris Wilson 2010-12-23 02:50:55 UTC
I'd throw that question to dri-devel@. There's a I915_PARAM_HAS_RELAXED_FENCING param that the driver could use to tune its heuristics for small textures on i915.
Comment 7 Samuel Degrande 2010-12-23 03:21:49 UTC
I have exactly the same issue with an i945 GPU (on Ubuntu 10.10)

Vendor     : Tungsten Graphics, Inc
Renderer   : Mesa DRI Intel(R) 945GME GEM 20100330 DEVELOPMENT x86/MMX/SSE2
Version    : 1.4 Mesa 7.9-devel
Comment 8 Arthur Huillet 2011-01-04 14:11:41 UTC
Created attachment 41649 [details] [review]
(untested) DRM patch to refuse tiling when it would artifically enlarge the texture

Would the attached patch be acceptable? It's a very simple solution that is not even really a hack. The logic is that on the older Intel chips (i915 and such) the minimal tiled texture size is 1MB, so we will refuse tiling if the actual input data is smaller than that, in order to make sure we do not eat too much memory.

Applications that upload lots of small textures will no longer be affected by the bug, while applications that behave well by creating texture atlases will not be negatively affected by the patch either.

(I have not fully tested the patch yet.)
Comment 9 Chris Wilson 2011-01-04 14:19:28 UTC
Along the right lines, but the policy needs to be in mesa not libdrm. xf86-video-intel has some rules on when an object is too small to tile that (I think) are reasonable heuristics.
Comment 10 Arthur Huillet 2011-01-05 10:35:28 UTC
Created attachment 41678 [details] [review]
7.9 7.10 Disable texture tiling for textures < 1024x1024

Mesa 7.9 and 7.10 use libdrm 2.4.21 and don't know about relaxed fencing. 

The attached patch is a proposed fix that implements the following very simple policy:

if (texture_width < 1024 && texture_height < 1024)
   no tiling

Please apply and push to the 7.9 and 7.10 branches, I'll create a patch for master that takes relaxed fencing into account.
Comment 11 Ian Romanick 2011-01-06 13:45:52 UTC
(In reply to comment #10)
> Created an attachment (id=41678) [details]
> 7.9 7.10 Disable texture tiling for textures < 1024x1024
> 
> Mesa 7.9 and 7.10 use libdrm 2.4.21 and don't know about relaxed fencing. 
> 
> The attached patch is a proposed fix that implements the following very simple
> policy:
> 
> if (texture_width < 1024 && texture_height < 1024)
>    no tiling
> 
> Please apply and push to the 7.9 and 7.10 branches, I'll create a patch for
> master that takes relaxed fencing into account.

Most textures are smaller than 1Kx1K, so this effectively disables texture tiling.  Texture tiling is a significant performance win.  I'm not going to degrade the performance of 90% of the users to benefit 10%.  Chris suggested using the same heuristic at xf86-video-intel (see intel_uxa.c, line 162ish):

 - Pitch greater than 8KiB

 - Pitch less than 256 bytes

 - Total texture size < 512KiB

At this point, I'm not real comfortable with any change going into the release trees for this.  I'll want any fix to have more soak time to make sure it doesn't cause regression and to make sure it actually fixes the problem.

In the mean time, there is a known work around.
Comment 12 Arthur Huillet 2011-06-14 01:27:24 UTC
No longer relevant with recent kernels, which makes this bug only appear on older distros and setup.
I am comfortable asking users to upgrade to a more recent version of kernel+Mesa, so a fix for this problem is no longer a priority for me.

I suggest closing the issue as there does not seem to be anyone interested in seeing it fixed any longer.
Comment 13 Eugeni Dodonov 2011-08-22 11:55:27 UTC
Let's close it as fixed then, as it is fixed on latest mesa, and backporting to older releases is unlikely.

Please feel free to reopen it if you disagree though..


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.