Created attachment 41374 [details]
Small OpenGL program that uploads lots of small textures
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.
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
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.
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
It's neither a stability fix nor is it trivial. The easiest workaround is to disable tiling by setting "texture_tiling = false" in driconf.
Thanks for the hint.
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.
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.
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
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.)
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.
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)
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.
(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
> 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.
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.
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..