24be011901 ("lima: wire up MSAA 4x support") switched to aligning all the
buffers to tile size and it resulted in allocating 16x more memory for
index, vertex and constant buffers.
We only want to align textures and render targets to tile size, not
other buffers, so restore old logic, but relax it.
Fixes: 24be011901 ("lima: wire up MSAA 4x support")
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17283>
They aren't supported and lead to GPU hangs.
Reported-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
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/17256>
The feature we wanted to enable in 710393b3aa was
descriptorBindingUniformBufferUpdateAfterBind.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 710393b3aa ("anv: enable UBO indexing")
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17200>
This is hit using lavapipe with zink on top running
dEQP-GL45-ES31.functional.primitive_bounding_box.wide_points.global_state.vertex_tessellation_fragment.default_framebuffer_bbox_equal
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17270>
When the stencil aspect of a depth+stencil texture is sampled, it's
actually integer. Also fixup st_translate_color() that assumed it was
float. This fixes the border color on zink+turnip.
v2: Add "|| texBaseFormat == GL_STENCIL_INDEX" to catch the case where
S8 is emulated as D24S8.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
On a650+ we use the new Z24UINT_S8UINT format to sample the stencil
aspect of D24S8, which returns stencil in the second component and also
uses the second integer component for the border color. However Vulkan
mandates that the first component is used for the stencil border color.
There's no workaround we know of, so we have to fall back to the old
behavior where there is a workaround. If we know the format, we can
fixup the border color ourselves though.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
From the API's point of view, border color replacement looks like this:
--------------------
| API Border Color |
--------------------
|
----------- | ---------------- ----------
| API fmt |-------->| User Swizzle |----->| Shader |
----------- ---------------- ----------
From the HW point of view, it looks like this:
-------------------
| HW Border Color |
-------------------
|
---------- ----------- | --------------- ----------
| HW fmt |-----| HW swap |------>| Tex Swizzle |----->| Shader |
---------- ----------- --------------- ----------
When the HW fmt + HW swap isn't enough to represent an API format, we
need to prepend our own swizzle to the the user's swizzle, so the tex
swizzle is a "format swizzle" composed with the user swizzle. However,
we don't want this format swizzle to be applied to border colors, so
there's a workaround in freedreno which is meant to undo the format
swizzle so that the HW border color with the format swizzle applied
equals the API border color, and everything is ok. However, on a6xx at
least it was incorrectly undoing the entire tex swizzle. This broke
border color with a user swizzle, because it was now effectively not
getting applied for the border color. It also made it seem like the user
swizzle is required for the workaround, which would have implications
for VK_EXT_border_color_swizzle with turnip, but it's not.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
virgl: Also drop old pre-trim glxgears trace (cached).
Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Emma Anholt <emma@anholt.net>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17280>
LAVA job logs have an ongoing problem of message interleaving with kmsg.
So any kernel dumps and LAVA signals (which are being printed in kmsg)
will have a chance to clutter the pattern matching for `hwci: mesa:
(pass|fail)` line.
v2:
- Add an 1 second sleep before exiting the test script, to give enough
time to print the result message without conflicting with LAVA ENDTC
signal from kmsg
Closes: #6714
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17175>
Early depth test is broken when the linear render target mode is used
and depth is written from the PE stage. It seems RA and PE disagree
about the cache layout in that case, so the RA sees unwritten/invalid
depth cache lines leading to random depth test fails. Early test works
fine if depth is written from the RA stage.
To work around this issue, detect the combination of linear RT, early
test and late write and switch to late test in that case.
Fixes: 53445284a4 ("etnaviv: add linear PE support")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17215>
On-GPU LRZ direction tracking allows LRZ to support secondary cmdbufs,
reusing LRZ between renderpasses, and in future to support LRZ when
VK_KHR_dynamic_rendering is used.
With on-gpu tracking we have to be careful keeping LRZ state in sync
with underlying depth image, which means we should invalidate LRZ
when underlying image is changed or the view of image is different
from previous renderpass.
All of this resulted in LRZ logic being thinly spread through the code,
making it hard to understand. So most of it was moved to tu_lrz.c.
For more details on past and new LRZ features see comment at the
top of tu_lrz.c.
Note about blob:
- Blob is much more happy to do LRZ_FLUSH, it flushes at the start
of the renderpass, after binning, and at the end of the renderpass.
- Blob seem not to care about changes in depth image done via
vkCmdCopyImage.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6347
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16251>
since !17208 there are 2 paths for disk_cache_get_function_identifier
on mingw: DETECT_OS_WINDOWS or HAVE_DLADDR (if dlfcn shims is present)
../src/util/disk_cache_os.c:47:1: error: redefinition of 'disk_cache_get_function_identifier'
47 | disk_cache_get_function_identifier(void *ptr, struct mesa_sha1 *ctx)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/util/disk_cache_os.c:36:
../src/util/disk_cache.h:121:1: note: previous definition of 'disk_cache_get_function_identifier' with type '_Bool(void *, struct _SHA1_CTX *)'
121 | disk_cache_get_function_identifier(void *ptr, struct mesa_sha1 *ctx)
here we disable the dladdr path from meson for consistency with msvc
fixes: 2dcbe8727
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17261>
We are already caching DXIL shaders individually, but that forces us
to retrieve the NIR shader, do the linking and binding translation
steps, to finally query the cache for each DXIL shader. This pipeline
caching is about skipping those steps when we can.
Note that a graphics/compute pipeline cache entry doesn't contain the
DXIL shaders, but hashes to retrieve those shaders from the same cache.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17140>
Binding translation has an impact on the final DXIL shader, and this
binding translation depends on the pipeline layout. Let's extend the
adjust_var_bindings() pass to caculate a hash we can then use in the
DXIL shader hash caculation.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17140>
Basically what vk_pipeline_cache's raw_data_object abstraction provides,
but I'm not sure it makes sense to make it generic so I copied it here.
Might be more appropriate to make raw_data_object public.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17140>
DXIL shaders depend on the vulkan -> d3d12 binding translation done in
adjust_var_bindings(). In order to maximize our chances to re-use those
shaders, we need to hash the binding translation information and take
this hash into account when computing the DXIL shader hash.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17140>
We will need to hash var bindings if we want to cache DXIL shaders.
Let's move this pass to dzn_pipeline.c to prepare this transition.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17140>
We leak the nir_shader object f a failure happens between the NIR
shader creation and the DXIL compilation. Let's drop the local
nir_shader pointer and use the one in the graphics_pipeline object
to avoid that.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17140>
This way we can use d3d12_pipeline_state_stream_new_desc() directly
without doing
if (type == GRAPHICS)
d3d12_gfx_pipeline_state_stream_new_desc()
else
d3d12_compute_pipeline_state_stream_new_desc()
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17140>
