In the Chrome WebGL Aquarium stress test, 20 instances of Chrome will run
Aquarium simultaneously over 20+ hours. That causes Chrome crash.
During the stress, glBeginQueryIndexed is called frequently.
1.Each query will only use 32 bytes from query_buffer_uploader. After the offset
exceed 4096, it will alloc new buffer for query_buffer_uploader->buffer
and release the old buffer.
2.But iris_begin_query will call u_upload_alloc when the offset changed, and it
will increase the query_buffer_uploader->buffer->reference.count every time
when it called u_upload_alloc.
3.So when u_upload_release_buffer try to release the resource of
query_buffer_uploader->buffer, its reference.count is
already equal to 129. pipe_reference_described will only decrease its reference
count to 128.So it never called old_dst->screen->resource_destroy.
4.The old resouce bo will never be freeed. And chrome will called mmap every time
when it alloc new resource bo.
5. Chrome process map too many vmas in its process. Its map count exceed the
sysctl_max_map_count which is 65530 defined in kernel.
6. When iris_begin_query want to alloc new resource bo, it will meet NULL pointer
because mmap return failed. Finally chrome crashed when it access this NULL resource
bo.
The fix is decrease the reference count in iris_destroy_query.
Patch is verified by chrome webgl Aquarium test case for more than 72 hours.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: Yang Shi <yang.a.shi@intel.com>
Reviewed-by: Alex Zuo <alex.zuo@intel.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7890>
PIPE_MAX_CONSTANT_BUFFERS is 32, however many Vulkan implementations
has maxPerStageDescriptorUniformBuffers that exceeds it, for example:
radv 8388606,
anv 64
nvidia 1048580 for RTX 2000 and up.
and, together with the current zink logic, the returned value
will exceed the maximum allowed value for the cap.
This causes cso_destroy_context to pass big values back to zink
(via zink_set_constant_buffer), resulting in access beyond end of
allocated buffer for all UBOs.
Cap the cap to PIPE_MAX_CONSTANT_BUFFERS (32), not INT_MAX.
Add an assert to verify future drivers.
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Fixes: daaf5f1d18 ("gallium: Fix leak of currently bound UBOs at CSO context destruction.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7976>
This looks like a typo. Packed vulkan formats should always map to the
inverse order of the corresponding gallium notation. Besides, it makes
no sense that unsigned and signed formats have different ordering.
Fixes: cdfb1d925f ("zink: add last few format maps for ARB_vertex_type_2_10_10_10_rev")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7964>
There's no good reason why drivers that doesn't grok geometry,
tesselation or compute shaders needs to deal with them.
This fixes a crash on a lot of Piglit tests for Zink.
Fixes: daaf5f1d18 ("gallium: Fix leak of currently bound UBOs at CSO context destruction.")
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7971>
Fixes the following building error:
FAILED: ninja: 'external/mesa/src/gallium/drivers/freedreno/freedreno_log.c',
needed by 'out/target/product/x86_64/obj_x86/STATIC_LIBRARIES/libmesa_pipe_freedreno_intermediates/freedreno_log.o',
missing and no known rule to make it
Fixes: 03e7c93b82 ("freedreno: Remove fd_log()")
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7942>
Changelog:
- add freedreno_tracepoints.c.{c,h} gen rules for Android $(MESA_PYTHON3)
- update Makefile.sources with the required generated sources
Fixes the following building errors:
external/mesa/src/gallium/drivers/freedreno/freedreno_gmem.c:35:10:
fatal error: 'u_tracepoints.h' file not found
^~~~~~~~~~~~~~~~~
1 error generated.
FAILED: out/target/product/x86_64/obj/SHARED_LIBRARIES/gallium_dri_intermediates/LINKED/gallium_dri.so
...
ld.lld: error: undefined symbol: __trace_end_clear_restore
>>> referenced by freedreno_tracepoints.h:38 (out/target/product/x86_64/obj/STATIC_LIBRARIES/libmesa_pipe_freedreno_intermediates/
freedreno_tracepoints.h:38)
...
ld.lld: error: undefined symbol: __trace_start_vsc_overflow_test
>>> referenced by freedreno_tracepoints.h:272 (out/target/product/x86_64/obj/STATIC_LIBRARIES/libmesa_pipe_freedreno_intermediates
/freedreno_tracepoints.h:272)
ld.lld: error: too many errors emitted, stopping now
Fixes: a02dcb970f ("freedreno: Add GPU tracepoints")
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7942>
Android rules to build u_trace sources and u_tracepoints generated sources
Changelog:
- add util/u_tracepoints.{c,h} gen rules for Android using $(MESA_PYTHON3)
- update Makefile.sources with the required sources and generated sources
Fixes: 3471af9c6c ("gallium/aux: Add GPU tracepoint mechanism")
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7942>
This is in preparation for additional generated sources rules for Android
which will require ad hoc rules, so it is necessary to replace old ones
NOTE: pre-existing gen rules based on $(transform-generated-source) macro
are both obsolete and use of '%' pattern rule is incompatible with ad hoc
python commands for different targets
Changelog:
- remove util/u_format_srgb.c target
- replace obsolete indices/{u_indices,unfilled}_gen.c 'common' gen rules
with 'per target' gen rules using $(MESA_PYTHON3) as per meson gen rules
Fixes: 3471af9c6c ("gallium/aux: Add GPU tracepoint mechanism")
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7942>
MoltenVK does not export the vkGetPhysical*2() functionns, even in Vulkan 1.2.154.0 where the instance version moves from 1.0 to 1.1.
If the extension is present and used the KHR versions of the functions can be used.
From the spec the vkGetPhysicalDevice*2() functions should be avaiable from Vk 1.1 loaders and devices. Which implies MoltenVK might be misbehaving.
This change allows the extension to be used, if present, before the Vk 1.1 version check.
Fixes: 752f6d80 ("zink: setup version dependent VkPhysicalDeviceVulkan*Features and VkPhysicalDeviceVulkan*Properties.")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7960>
We were returning a pointer to use-after-free the depth buffer, not
updating it in after future rendering, and also not y flipping it. A
little refactor to mostly reuse the color buffer's path makes it easy to
do it all right.
Adds a unit test to check for these bugs.
Closes: #885
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7886>
If we don't do that, the line_stride might be wrong. We also need
to create a new BO if the previous one is too small to hold the
linear version, which can happen with the tile alignment done on
linear+renderable resources.
Suggested-by: Icecream95
Fixes: d4f662a252 ("panfrost: Update the resource layout when doing a tile -> linear conversion")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7821>
