When freeing a buffer, we may return a non-idle buffer to the cache,
which means we cannot unmap aux entries at that time. Instead, we
defer unmapping the stale aux entry until we reuse a BO from the cache.
Unfortunately, this can lead to a recursive locking issue:
1. intel_aux_map_add_mapping wants to set up a new aux entry
It takes the intel_aux_map_context::mutex lock, then calls:
add_mapping -> get_aux_entry -> add_sub_table -> add_buffer ->
intel_aux_map_buffer_alloc -> iris_bo_alloc
2. iris_bo_alloc tries to allocate a BO from the cache, doing:
alloc_bo_from_cache -> intel_aux_map_unmap_range ->
intel_aux_unmap_range
...which then tries to take the intel_aux_map_context::mutex lock.
But it is already locked.
One solution would be to rework the aux map handling code to allocate
BOs without holding its lock, but that looks to be painful. Another
is to make the lock recursive, but we try and avoid that. A third
option wuold be to add a BO_ALLOC flag that makes alloc_bo_from_cache
skip any buffers with aux_map_address != 0 so we don't have to unmap,
making the less cache effective but fixing the recursive lock.
A fourth option is to simply bypass the BO cache altogether for the
buffers that hold the aux map itself. Allocating new BOs for the aux
tables should be relatively rare, so there's probably not a lot of
benefit in using the BO cache.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5191
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12420>
v2: use vk_alloc instead of vk_zalloc because of full memcpy
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com> (v1)
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12499>
This extension relaxes the alignment requirements to allow the GL std430
layout to be used. freedreno/ir3 already supports this (via
PIPE_CAP_LOAD_CONSTBUF).
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12495>
With hw devices, when you submit a present, implicit sync will
make sure the work submitted to the gpu on the client will end
up happening before the present work submitted on the server.
However with sw paths there is no real GPU, the lavapipe fake
GPU thread is client side only and presenting is done directly
from the pixmap (or later shared pixmap). In order for this to
make sense the wsi common code should wait for the fence on the
image before queueing the submit to the server so that all
client works has been flushed to the pixmap before the copy or
present operation is submitted.
Fixes: 8004fa9c95 ("vulkan/wsi: add sw support. (v2)")
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12502>
When rasterizing legacy-lines, OpenGL defines the width as being an
extrusion along the minor axis, repeating varyings. While the spec
*does* allow for an alternative method that matches our current results,
the OpenGL ES CTS doesn't allow these results even if OpenGL ES has the
same wording of an alternative method.
This is technically speaking a bug in the OpenGL ES CTS, but it seems
like nobody else is using the alternative formulation, at least not
while passing the OpenGL ES CTS. On top of this, the OpenGL specification
explicitly lists the extrusion results as the preferred method.
So it seems like a good idea for us to do this the way the OpenGL
specification prefers regardless; it's going to give less surprising
results to applications, and it's helping us pass some tests.
This math to set these up would "trivially" be:
dx = (dx * dx + dy * dy) / dx
dy = 0
and:
dy = (dx * dx + dy * dy) / dy
dx = 0
...but since we've already calculated dxdy, we can reformulate this to
save a division.
This fixes the following dEQP test-cases:
- dEQP-GLES2.functional.rasterization.interpolation.basic.line_loop_wide
- dEQP-GLES2.functional.rasterization.interpolation.basic.line_strip_wide
- dEQP-GLES2.functional.rasterization.interpolation.basic.lines_wide
- dEQP-GLES2.functional.rasterization.interpolation.projected.line_loop_wide
- dEQP-GLES2.functional.rasterization.interpolation.projected.line_strip_wide
- dEQP-GLES2.functional.rasterization.interpolation.projected.lines_wide
- dEQP-GLES3.functional.rasterization.fbo.rbo_singlesample.interpolation.lines_wide
- dEQP-GLES3.functional.rasterization.fbo.texture_2d.interpolation.lines_wide
- dEQP-GLES3.functional.rasterization.interpolation.basic.line_loop_wide
- dEQP-GLES3.functional.rasterization.interpolation.basic.line_strip_wide
- dEQP-GLES3.functional.rasterization.interpolation.basic.lines_wide
- dEQP-GLES3.functional.rasterization.interpolation.projected.line_loop_wide
- dEQP-GLES3.functional.rasterization.interpolation.projected.line_strip_wide
- dEQP-GLES3.functional.rasterization.interpolation.projected.lines_wide
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11315>
Seems we haven't encountered this before because
nir_lower_io_to_scalar_early usually scalarizes this.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12486>
This has never been used because it requires to know the previous
clear values which is not really possible in Vulkan.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12326>
We would like draw-only display lists to have immutable draw info and
this is the only GL non-draw state in pipe_draw_info (not counting
view_mask).
It also allows removing some code from draw_vbo for tessellation.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12351>
Fixes framebuffer_fetch and blend_equation_advanced dEQP tests on v6.
v2: Use clause dependencies rather than comparing the message type
v3: Shift the BIFROST_SLOT_* constants before using them as a mask
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12375>
Two related changes:
- in tu_device.c:tu_CreateDevice we need to free both pointers in the
teardown path after tu_bo_finish(global_bo), which uses the pointers.
They are allocated in the first call to tu_bo_init(), which happens
when global_bo is allocated.
- in tu_drm.c:tu_bo_init we need to free bo_list if the bo_idx
allocation fails. Convert to the goto teardown pattern as well.
Fixes the following dEQP-VK tests:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail
dEQP-VK.api.object_management.alloc_callback_fail.device
dEQP-VK.api.object_management.alloc_callback_fail.device_group
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12481>
Apparently, CLPER_V7 is missing from Mali G31, but CLPER_V6 works. Fixes
INSTR_INVALID_ENC faults and failures in
dEQP-GLES3.functional.shaders.derivate.* on Dvalin.
Technically not an errata but an implementation difference. I suspect
Mali G51 will need this as well, should we ever allowlist it.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
ST_TILE lets us specify an explicit sample, whereas BLEND replicates to
all samples. This fully fixes the interaction between blend shaders and
multisampling on Bifrost, manifesting as
dEQP-GLES3.functional.fragment_ops.random.* failures with the
configuration rgba8888d24s8ms4.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
This varies the sample ID value, which will be used in the next commit.
This is less complicated than keying blend shaders to the content of
this flag and trying to make mega blend shaders covering all samples at
once ... complexity I'd rather not think about right now. The DDK does
it this way.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
Use the explicit sample mode and set the sample ID in the pixel indices
structure to the current sample ID. This fixes tilebuffer loads in blend
shaders on multisampled framebuffers.
Make sure the new routine is broken out to a helper for use with ST_TILE
in the next commit.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
This breaks screen-space derivatives in a shader that uses multiple
render targets, if the derivative calculation is scheduled after a BLEND
instruction calling into a blend shader.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
I don't think we'll ever hit this in practice, since it's not needed for
blend shaders, but better to correct the code anyway.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
Although it is passing all of dEQP-GLES31, it is failing a few
KHR-GLES31.* tests. It also has performance issues at the moment. Invert
the existing noindirect debug flag to become a indirect debug flag. Set
this flag for dEQP-GLES31 CI on G52, to make sure the code doesn't bit
rot on the hope someone will pick this up later on.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12478>
struct wsi_wl_image is only used as member of the swapchain, and during
the swapchain creation the image is already initialized to zero. So we
have no problems with members of the image being used uninitialized.
But for consistency, memset the members of this struct to zero in
wsi_wl_image_init(). This can help to avoid problems in the future.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12451>
In wsi_wl_surface_create_swapchain() we have a piece of code to init
some members of the chain to 0, in order to allow us to call
wsi_wl_swapchain_destroy() for cleanup.
Instead, we can use vk_zalloc() to allocate the chain, as it initializes
all members of the struct to zero. This help us to avoid problems when
people add new members to the struct and forget to initialize them.
Also, it makes the code look better.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12451>
This catches use-after-frees and buffer overflows, but not leaks (which we
disable the checking for since the library gets dlclose()d and we end up
with useless backtraces).
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8889>
Tomeu Vizoso
Kenneth Graunke
Yiwei Zhang
Matt Turner
Samuel Pitoiset
Dave Airlie
Rhys Perry
Erik Faye-Lund
Daniel Schürmann
Michel Zou
Ian Romanick
Marek Olšák
Connor Abbott
Rob Clark
Icecream95
Alyssa Rosenzweig
Leandro Ribeiro
Emma Anholt