mesa issueshttps://gitlab.freedesktop.org/mesa/mesa/-/issues2020-09-24T16:32:06Zhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/3513Massive memory leak (at least AMD, others unknown)2020-09-24T16:32:06Znewperson1746Massive memory leak (at least AMD, others unknown)Hi,
First time here-- found out about here through Ubuntu's oibaf ppa. Recently as of September 11th's mesa compile by oibaf (20.3~git2009110730.65d0fa~oibaf~f) mesa is leaking massive amounts of memory. On 8G of ram with an r9 290, ram...Hi,
First time here-- found out about here through Ubuntu's oibaf ppa. Recently as of September 11th's mesa compile by oibaf (20.3~git2009110730.65d0fa~oibaf~f) mesa is leaking massive amounts of memory. On 8G of ram with an r9 290, ram fills completely up in about 10-15 minutes. After that, the system begins to swap to the 8G swap partition for another 10 or so minutes. Then, oom-killer starts killing processes before the system completely freezes.
It's not any process or update; I have traced it down to only that mesa update. Reverting from oibaf's ppa to stock drivers immediately fixes the issue. Reverting to any compile before that also fixes the issue. Also, `ps aux | awk '{sum+=\$6} END {print sum / 1024}'` gives a count of actual process memory in megabytes, and it is never all of system ram. This has to be somewhere in the drivers.
Not sure if its AMD-only or otherwise. I do know that I am already not the only one to have experienced this; here's a reddit post with other affected users, including reproductions of the bug on non-ubuntu/non-oibaf compiles of mesa git: https://www.reddit.com/r/Ubuntu/comments/ir9kvx/ubuntu_2004_possible_memory_leak_with_gnomeshell
I posted the bug on r/linux as well https://www.reddit.com/r/linux/comments/irnrqv/warning_about_a_brandnew_memory_leak_in_mesa_at/ to find out whether its AMD-exclusive or affects everyone.
Occurs on both wayland and Xorg. Believe it or not, it's not gnome this time.
**System**
R9 290 4096MB
G3258 @ 4.5GHz
8192MB DDR3
amdgpu (not radeon) kernel module
Oibaf Mesa (build string: 20.3~git2009110730.65d0fa~oibaf~f)
Ubuntu 20.04Mesa 20.2.0 release trackerhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/3406radv: Corruption in "The Surge 2"2020-09-11T21:23:25ZBas Nieuwenhuizenradv: Corruption in "The Surge 2"image: https://steamcommunity.com/sharedfiles/filedetails/?id=2195556386
```
commit af81486a8cde4dec2a695884b93b282c1710d8bd (HEAD)
Author: Jason Ekstrand <jason@jlekstrand.net>
Date: Thu May 28 18:32:01 2020 -0500
spirv: Simplif...image: https://steamcommunity.com/sharedfiles/filedetails/?id=2195556386
```
commit af81486a8cde4dec2a695884b93b282c1710d8bd (HEAD)
Author: Jason Ekstrand <jason@jlekstrand.net>
Date: Thu May 28 18:32:01 2020 -0500
spirv: Simplify our handling of NonUniform
The original implementation of SPV_EXT_descriptor_indexing was extremely
paranoid about the NonUniform qualifier, trying to fetch it from every
possible location and propagate it through access chains etc. However,
the Vulkan spec is quite nice to us on this and has very strict rules
for where the NonUniform decoration has to be placed. For image and
texture operations, we can search for the decoration on the spot when we
process the image or texture op. For pointers, we continue putting it
on the pointer but we don't bother trying to do anything silly like
propagate it through casts.
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5278>
```
I realize there is a glslang bug open for the behavior (https://github.com/KhronosGroup/glslang/issues/2357), but we actually have games using this and we should avoid regressing them.
"Detroit become human" also uses descriptor indexing, so could potentially be impacted (haven't tested yet)Mesa 20.2.0 release trackerhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/3399[iris][regression] mesa 20.2: piglit failures on multiple platforms2020-08-13T02:35:40Zngcortes[iris][regression] mesa 20.2: piglit failures on multiple platformsThese test failures were found on mesa=d4d36010a82 with the following shas for the testing components:
crucible=ae2fae4 cts=01928c37e deqp=ee2101f34 drm=669e1087 glcts=77ccafb56 glslang=b60e067b kc-cts=d937540 mesa=d4d36010a82 piglit=b7...These test failures were found on mesa=d4d36010a82 with the following shas for the testing components:
crucible=ae2fae4 cts=01928c37e deqp=ee2101f34 drm=669e1087 glcts=77ccafb56 glslang=b60e067b kc-cts=d937540 mesa=d4d36010a82 piglit=b7836091a spirvheaders=3fdabd0 spirvtools=7b2dd11dd vkrunner=f688a74 vulkancts=27e691f02 waffle=a1215f4
Below is each failing test and the platform(s) on which it fails:
```
piglit.shaders.glsl-fs-loop-while-false-03 # no bug
icl_iris, bdw_iris, tgl, gen9atom_iris, gen9_iris
```Mesa 20.2.0 release trackerhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/3400[i965][regression] mesa 20.2: piglit failures on multiple platforms2020-08-12T21:45:38Zngcortes[i965][regression] mesa 20.2: piglit failures on multiple platformsThese test failures were found on mesa=d4d36010a82 with the following shas for the testing components:
crucible=ae2fae4 cts=01928c37e deqp=ee2101f34 drm=669e1087 glcts=77ccafb56 glslang=b60e067b kc-cts=d937540 mesa=d4d36010a82 piglit=b7...These test failures were found on mesa=d4d36010a82 with the following shas for the testing components:
crucible=ae2fae4 cts=01928c37e deqp=ee2101f34 drm=669e1087 glcts=77ccafb56 glslang=b60e067b kc-cts=d937540 mesa=d4d36010a82 piglit=b7836091a spirvheaders=3fdabd0 spirvtools=7b2dd11dd vkrunner=f688a74 vulkancts=27e691f02 waffle=a1215f4
Below is each failing test and the platform(s) on which it fails:
```
piglit.spec.!opengl 1_0.rasterpos
ivb, g965, hsw, g45, gen9, bdw, icl, ilk, byt, snb, bsw, gen9atom
```Mesa 20.2.0 release trackerhttps://gitlab.freedesktop.org/mesa/mesa/-/issues/3393[iris][bisected][regression] piglit,deqp,glcts failures on multiple platforms2020-08-12T02:06:06Zngcortes[iris][bisected][regression] piglit,deqp,glcts failures on multiple platformsIssues began with mesa=a494b6241016d3d5995902748b40c70ae8d1ecbd:
```
Author: Timothy Arceri <tarceri@itsqueeze.com>
Date: Wed Apr 29 12:20:47 2020 +1000
glsl: remove dead uniforms in the nir linker
This is now possible as...Issues began with mesa=a494b6241016d3d5995902748b40c70ae8d1ecbd:
```
Author: Timothy Arceri <tarceri@itsqueeze.com>
Date: Wed Apr 29 12:20:47 2020 +1000
glsl: remove dead uniforms in the nir linker
This is now possible as we do uniform linking via a nir based linker.
Shader-db results for IRIS (SKL):
total instructions in shared programs: 14947192 -> 14946397 (<.01%)
instructions in affected programs: 39498 -> 38703 (-2.01%)
helped: 230
HURT: 18
total cycles in shared programs: 324868402 -> 324847058 (<.01%)
cycles in affected programs: 706701 -> 685357 (-3.02%)
helped: 599
HURT: 449
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4797>
```
Sample output from KHR-GLES31.core.layout_binding.atomic_uint_layout_binding_atomic_FragmentShader on icl_iris:
stdout:
```
This test was not run for this context as it does not apply.
offset ofatomic2did not match requested expected: 4 actual: 0
#version 310 es
precision highp float;
precision highp atomic_uint;
layout(location=0) in vec2 inPosition;
flat out vec4 fragColor;
void main(void)
{
gl_Position = vec4(inPosition, 0.0, 1.0);
}
#version 310 es
precision highp float;
precision highp atomic_uint;
layout(location=0) out vec4 outColor;
flat in vec4 fragColor;
layout(binding=3, offset=4) uniform atomic_uint atomic0;
layout(binding=2) uniform atomic_uint atomic1;
layout(binding=3) uniform atomic_uint atomic2;
layout(binding=2) uniform atomic_uint atomic3;
void main(void)
{
outColor = vec4(float(atomicCounter(atomic0)), 1.0, 0.0, 1.0);
+vec4(float(atomicCounter(atomic1)), 1.0, 0.0, 1.0);
+vec4(float(atomicCounter(atomic2)), 1.0, 0.0, 1.0);
+vec4(float(atomicCounter(atomic3)), 1.0, 0.0, 1.0);
}
```
stdout:
```
pid: 259622
```Mesa 20.2.0 release trackerTimothy ArceriTimothy Arceri