[Bug 104760] System hang when use glTexImage3D to specify a 3D texture image

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Aug 3 13:13:24 UTC 2018


Danylo <danylo.piliaiev at gmail.com> changed:

           What    |Removed                     |Added
                 CC|                            |danylo.piliaiev at gmail.com

--- Comment #17 from Danylo <danylo.piliaiev at gmail.com> ---
Kernel was bisected to commit 40e62d5d6be8b4999068da31ee6aca7ca76669ee:
 drm/i915: Acquire the backing storage outside of struct_mutex in set-domain

It seems that before that patch memory wasn't immediately allocated but I could
be wrong.
Also it seems that OOM killer doesn't know about such allocations and doesn't
kill example application until the very end.

However why are we even able to request such a big allocation when creating a
There is a Const.MaxTextureMbytes, checking against which should prevent
creation of such texture.

i965 doesn't provide custom TestProxyTexImage and uses
_mesa_test_proxy_teximage which doesn't take 'level' into account so the
texture with dimensions of 1x1x1 and level=11 easily passes the check.

Later in intel_miptree_create_for_teximage the dimensions of the image at level
0 are determined to be 2048x2048x2048 but at this moment there are no checks of
resulting image size.

The solution to this may be a creation of custom TestProxyTexImage where the
size of the image at level 0 will be checked. So the texture size will always
obey the limits.

Also I found that in radeon_miptree_create_for_teximage there are special
checks for height and depth being 1, in such case they will be 1 at all levels.
Just an observation...

To sum up:

- One issue is that texture size limit is enforced inconsistently and it can be
fixed in Mesa.
- Second is OOM killer being unable to cope with this type of allocations. I
don't have any knowledge about this one.

You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20180803/5b57ec40/attachment.html>

More information about the intel-3d-bugs mailing list