For instance, this issue is triggered with "piglit/bin/fcc-blit-between-clears -auto -fbo":
Direct leak of 16400 byte(s) in 5 object(s) allocated from:
#0 0xb720689a in __interceptor_calloc (/usr/lib/libasan.so.6+0xb289a)
#1 0xaf10f896 in draw_create_fragment_shader ../src/gallium/auxiliary/draw/draw_fs.c:47
#2 0xaef64619 in i915_create_fs_state ../src/gallium/drivers/i915/i915_state.c:550
#3 0xae16a955 in ureg_create_shader ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2194
#4 0xae17f45f in ureg_create_shader_with_so_and_destroy ../src/gallium/auxiliary/tgsi/tgsi_ureg.h:150
#5 0xae17f45f in ureg_create_shader_and_destroy ../src/gallium/auxiliary/tgsi/tgsi_ureg.h:159
#6 0xae17f45f in util_make_fs_blit_zs ../src/gallium/auxiliary/util/u_simple_shaders.c:365
#7 0xaf13300e in blitter_get_fs_texfetch_depth ../src/gallium/auxiliary/util/u_blitter.c:1157
#8 0xaf13300e in util_blitter_cache_all_shaders ../src/gallium/auxiliary/util/u_blitter.c:1322
#9 0xaef6b738 in i915_create_context ../src/gallium/drivers/i915/i915_context.c:233
#10 0xacb33c49 in st_api_create_context ../src/mesa/state_tracker/st_manager.c:986
#11 0xac845740 in dri_create_context ../src/gallium/frontends/dri/dri_context.c:178
#12 0xac854d97 in driCreateContextAttribs ../src/gallium/frontends/dri/dri_util.c:631
#13 0xb6ce79a3 in dri2_create_context_attribs ../src/glx/dri2_glx.c:240
#14 0xb6c9606f in dri_common_create_context ../src/glx/dri_common.c:665
#15 0xb6ca4f00 in CreateContext ../src/glx/glxcmds.c:322
#16 0xb6ca5c0b in glXCreateNewContext ../src/glx/glxcmds.c:1449
Fixes: 1a69b50b3b ("i915g: Fix point sprites.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27570>
For instance, this issue is triggered with "piglit/bin/glx-multithread-texture -auto -fbo":
Direct leak of 256 byte(s) in 1 object(s) allocated from:
#0 0xb71eda62 in __interceptor_realloc (/usr/lib/libasan.so.6+0xb2a62)
#1 0xadd5a32f in tokens_expand ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:239
#2 0xadd5a32f in get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:262
#3 0xadd62519 in copy_instructions ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2079
#4 0xadd62519 in ureg_finalize ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2129
#5 0xadd64bde in ureg_get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2206
#6 0xade377d0 in nir_to_tgsi_options ../src/gallium/auxiliary/nir/nir_to_tgsi.c:4043
#7 0xade3da63 in nir_to_tgsi ../src/gallium/auxiliary/nir/nir_to_tgsi.c:3831
#8 0xaeb606c9 in i915_create_vs_state ../src/gallium/drivers/i915/i915_state.c:662
#9 0xac781a2c in st_create_common_variant ../src/mesa/state_tracker/st_program.c:720
#10 0xac78e8a4 in st_get_common_variant ../src/mesa/state_tracker/st_program.c:773
#11 0xac78fc10 in st_precompile_shader_variant ../src/mesa/state_tracker/st_program.c:1259
#12 0xac78fc10 in st_finalize_program ../src/mesa/state_tracker/st_program.c:1345
#13 0xac790b1a in st_program_string_notify ../src/mesa/state_tracker/st_program.c:1378
#14 0xace457a9 in _mesa_get_fixed_func_vertex_program ../src/mesa/main/ffvertex_prog.c:1397
#15 0xac5ef8db in update_program ../src/mesa/main/state.c:281
#16 0xac5f0ece in _mesa_update_state_locked ../src/mesa/main/state.c:560
#17 0xac5f1653 in _mesa_update_state ../src/mesa/main/state.c:593
#18 0xacdf9fe2 in _mesa_DrawArrays ../src/mesa/main/draw.c:1403
Fixes: 487a493325 ("i915g: Add support for per-vertex point size.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27570>
For instance, this issue is triggered with "piglit/bin/fcc-blit-between-clears -auto -fbo":
Direct leak of 836 byte(s) in 1 object(s) allocated from:
#0 0xb71eb6f2 in malloc (/usr/lib/libasan.so.6+0xb26f2)
#1 0xaefadc78 in slab_add_new_page ../src/util/slab.c:179
#2 0xaefadc78 in slab_alloc ../src/util/slab.c:221
#3 0xaef7d461 in i915_texture_transfer_map ../src/gallium/drivers/i915/i915_resource_texture.c:789
#4 0xac9e931e in pipe_texture_map ../src/gallium/auxiliary/util/u_inlines.h:555
#5 0xac9e931e in _mesa_map_renderbuffer ../src/mesa/main/renderbuffer.c:494
#6 0xad49c5e4 in readpixels_memcpy ../src/mesa/main/readpix.c:260
#7 0xad49c5e4 in _mesa_readpixels ../src/mesa/main/readpix.c:898
#8 0xad5d8cfe in st_ReadPixels ../src/mesa/state_tracker/st_cb_readpixels.c:568
#9 0xad4a0caf in read_pixels ../src/mesa/main/readpix.c:1199
#10 0xad4a0caf in _mesa_ReadnPixelsARB ../src/mesa/main/readpix.c:1216
#11 0xad4a155b in _mesa_ReadPixels ../src/mesa/main/readpix.c:1231
or "piglit/bin/fcc-read-to-pbo-after-clear -auto":
Direct leak of 772 byte(s) in 1 object(s) allocated from:
#0 0xb726b6f2 in malloc (/usr/lib/libasan.so.6+0xb26f2)
#1 0xaf0adc88 in slab_add_new_page ../src/util/slab.c:179
#2 0xaf0adc88 in slab_alloc ../src/util/slab.c:221
#3 0xaf07aad7 in i915_buffer_transfer_map ../src/gallium/drivers/i915/i915_resource_buffer.c:75
#4 0xad10de74 in pipe_buffer_map_range ../src/gallium/auxiliary/util/u_inlines.h:398
#5 0xad10de74 in _mesa_bufferobj_map_range ../src/mesa/main/bufferobj.c:499
#6 0xad5677ce in _mesa_map_pbo_dest ../src/mesa/main/pbo.c:308
#7 0xad59be3b in _mesa_readpixels ../src/mesa/main/readpix.c:894
#8 0xad6d8cfe in st_ReadPixels ../src/mesa/state_tracker/st_cb_readpixels.c:568
#9 0xad5a0caf in read_pixels ../src/mesa/main/readpix.c:1199
#10 0xad5a0caf in _mesa_ReadnPixelsARB ../src/mesa/main/readpix.c:1216
#11 0xad5a155b in _mesa_ReadPixels ../src/mesa/main/readpix.c:1231
Fixes: e7a73b75a0 ("gallium: switch drivers to the slab allocator in src/util")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27570>
If you suspect a workload is failing because it needs more memory, you
can set ANV_SYS_MEM_LIMIT=100 to give it all the memory available.
This could make, for example, certain games start working (it really
depends on how much RAM you have and how much the game wants).
If you suspect a workload is too resource hungry, you can try to limit
it with ANV_SYS_MEM_LIMIT=30 (or some other value) to see if it can
deal with the more restricted environment and behave accordingly.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28513>
"We paid for sixteen gigs of RAM, so we gonna use the whole damn
sixteen gigs of RAM!"
- My Mom
First, some history:
The Anv 50%-or-75% rule was originally added in 2017 by 060a6434ec
("anv: Advertise larger heap sizes"). When i915.ko started reporting
memory sizes in its ioctls, it didn't impose any restrictions: 100% of
SRAM was reported as available, so the restriction was in Mesa. When
xe.ko was introduced, it only reported 50% of the SRAM as available
through its ioctls, so commit b571ae6e7a ("intel: Make memory heaps
consistent between KMDs") adapted the code to not take an extra 25% of
the 50% that was already cut, and restricted i915.ko to 50% instead of
the 50%-or-75%. In Kernel commit d2d5f6d57884 ("drm/xe: Increase the
XE_PL_TT watermark"), xe.ko changed to reporting 100% of SRAM through
its ioctls, so we adapted Mesa to do the right thing depending on
which Kernel version was running.
While this was all happening, we were discussing about which behavior
was actually the best: restrict everything to 50% in order to avoid
issues when many things are running in parallel, or keep the
restriction only at 75% in order to allow high demanding workloads to
make full use of the hardware.
The way I see, if parallel applications are causing the system to run
out of resources, the user always has the option to kill applications
and use one thing at a time. On the other hand, if a single
application needs more than 50% of the SRAM and we don't allow it in
our heaps, the application will never work (unless, of course, the
user patches Mesa). So in this commit we go back to allowing
high-demanding applications to work by restoring the 50%-or-75% rule.
This commit is especially useful in systems with integrated graphics,
like LNL, where the option to upgrade RAM is not present.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28513>
Kernel commit d2d5f6d57884 ("drm/xe: Increase the XE_PL_TT watermark")
changed how xe.ko reportes memory: its ioctls now report 100% of the
system RAM as available. Since our policy is to report 50% of the SRAM
as available for the heaps, add some code to check the amount reported
by xe.ko against the amount reported by the system, then act
accordingly.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28513>
Before commit b571ae6e7a ("intel: Make memory heaps consistent
between KMDs"), we had the following policy for reporting Sytem RAM
memory sizes:
- For OpenGL, we reported the total available RAM.
- For Vulkan, we reported the total available RAM as:
- 50% of the total RAM if the total RAM was <= 4GB,
- 75% otherwise
- In addition, the Memory Budget (for VK_EXT_memory_budget) is 90%
of the "free" memory, which can be an extra 10% off of the 50% or
75%.
When xe.ko was added, one key difference was noted: while i915.ko
reported the "real" RAM memory sizes in its ioctls, xe.ko reported
only 50% of the system RAM as available. Because of that (and other
reasons, see this discussion on MR 28513), commit b571ae6e7a decided
to unify the behavior by changing the Anv i915.ko rule to "always 50%"
instead of "50% or 75%". This also changed the Iris rule to 50%
instead of 100%.
In my research, I couldn't find any reason why this restriction should
also apply to Iris, so here we revert back to handling these size
restrictions on Anv only.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28513>
This is necessary to appropriately uniformize the first component
access of a convergent vector. Without this, this is produced:
load_payload(16) %18:D, 0d, 0d NoMask group0
add(32) %21:F, %18+0.0:F, 0.5f
add(32) %22:F, %18+2.0<0>:F, 0.5f
This is the correct code:
load_payload(16) %18:D, 0d, 0d NoMask group0
add(32) %21:F, %18+0.0<0>:F, 0.5f
add(32) %22:F, %18+2.0<0>:F, 0.5f
Without 38b58e286f, the code generated was more incorrect, but happened
to work for this test case:
load_payload(16) %18:D, 0d, 0d NoMask group0
add(32) %21:F, %18+0.0<0>:F, 0.5f
add(32) %22:F, %18+0.4<0>:F, 0.5f
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 38b58e286f ("brw/nir: Fix source handling of nir_intrinsic_load_barycentric_at_offset")
Closes: #12969
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34427>
These options are equivalent to the corresponding panvk options.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34374>
These can be used to pin an application to specific cores. A tiler mask
option is not included because there is no current hardware that
includes more than one tiler.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34374>
This is needed for panvk, where we want to expose uint64 core masks. The
previous int parsing logic was technically UB rather than guaranteed
truncate-on-overflow, but was likely compiled to truncate in practice.
It is very unlikely that anyone was relying on this.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34374>
Makes the intention of some comparisons clearer by using the named
helper functions. Add commentary when the straightforward range is not
the one used, e.g. VGRF interference.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34253>
Indeed, this resource was assigned twice and was not properly freed.
For instance, this issue is triggered with:
"piglit/bin/glsl-fs-pointcoord -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: 0278d1fa32 ("gallium: add unbind_num_trailing_slots to set_vertex_buffers")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27572>
Add conditioning before making driver calls to be
able to workaround some of the fatal errors, such
as unboxing issues during or after snapshot load.
This enables invalidating a host dispatcher based
on the application state. A default error will be
returned for vulkan calls.
Builtin expectation function is used to reduce
performance cost of the checks.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34418>
Track pipeline layout creation and destroy calls
to cleanup them correctly on device teardown.
Pipeline layouts require delayed delete operations for
VulkanQueueSubmitWithCommands feature which modifies order
of commands and they need to stay valid during recording.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34418>
This tells it to actually panic instead of unwinding and returning NULL.
I find myself commenting out the unwind code pretty frequently so I can
get GDB to break at the panic. This should help avoid that extra debug
step.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34435>
We need different Temps for each resume shader, because registers aren't
preserved across resume boundaries.
This was likely fine in practice because arg registers are the same for
each shader, but resulted in invalid IR and asserts.
Fixes crashes in Indiana Jones RT with assertions enabled on GFX8.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34114>
VUID-VkDescriptorSetAllocateInfo-pSetLayouts-09380 says that :
"If pSetLayouts[i] was created with an element of pBindingFlags
that includes VK_DESCRIPTOR_BINDING_VARIABLE_DESCRIPTOR_COUNT_BIT,
and VkDescriptorSetVariableDescriptorCountAllocateInfo is included
in the pNext chain, and
VkDescriptorSetVariableDescriptorCountAllocateInfo::descriptorSetCount
is not zero, then
VkDescriptorSetVariableDescriptorCountAllocateInfo::pDescriptorCounts[i]
must be less than or equal to
VkDescriptorSetLayoutBinding::descriptorCount for the corresponding
binding used to create pSetLayouts[i]"
But applications like are not following the spec. RADV doesn't apply
that limit and allocates if there is enough space in the pool. Let's
just do the same.
Note that this issue got resolved with a vkd3d-proton change :
a7ac1a7d2f
But since this change is deleting more code than it adds, might as
well go with it.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12185
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32305>
