a framebuffer is based on the surfaces attached to it
a renderpass is based on the operations being performed
a zink_framebuffer object doesn't necessarily need to be changed
if the renderpass changes, as this might just indicate that a clear operation
is being used instead of a load, so we can cache the corresponding vk objects
into the zink_framebuffer based on the renderpass ops being used to (eventually)
reduce fb object thrashing by doing more incremental updates
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8227>
we don't want to actually be tracking any null surfaces, so instead use
the vk object for this purpose
also store the fb state onto the fb object so we have this info available
at all times
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8227>
IR3_SHADER_DEBUG=vs,tcs,tes... now also prints shader's sha1.
When there is a file named %sha1%.asm in IR3_SHADER_OVERRIDE_PATH
directory - ir3 assembly from file would be parsed, assembled, and
will override the shader with corresponding sha1 hash.
Parsing failure is considered unrecoverable error.
Upon successful override shader's assembly is printed with:
"Native code (overridden) for unnamed ..."
This debug option allows easier testing of small changes in
assembly without modifying the compiler or using computerator.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8388>
ssbos are the only descriptor type we support (so far) that allows writes
during the draw, so we have to ensure that we set the right flag on the batch
reference to handle sync if the buffer is later read from
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8330>
we have the technology, so now we can just flag these resources as being
read from instead of also being written to, freeing them up for concurrent reads
without requiring fencing
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8330>
if ssbo variables are declared using the same structure as ubos, then
the mechanics here are identical, and we can just add a couple extra lines
to handle the atomic ops and different array usage
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8330>
these all need specific memory params, but otherwise they're the same
as normal ops, so we can just make a helper function here to add in the memory
params
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8330>
if the table is filled with deleted entries, we don't need to rzalloc+free an identical
block of memory for the table, we can just memset the existing one
the same applies to table clears without a function passed in that the table
doesn't need to be iterated and can just be memset
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8450>
if the table is filled with deleted entries, we don't need to rzalloc+free an identical
block of memory for the table, we can just memset the existing one
the same applies to table clears without a function passed in that the table
doesn't need to be iterated and can just be memset
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8450>
If we don't tag compute sgpr as dirty they will point to the
ol buffer location.
This fixes arb_compute_shader-dlist with mcbp enabled.
Fixes: 85a6bcca61 ("radeonsi: pass at most 3 images and/or shader buffers via user SGPRs for compute")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8433>
The former allows specifying how many processes to spawn for tests. The
latter seems to spawn (up to) as many test processes as there are CPU
cores.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8451>
We sometimes use anv_layout_to_aux_state() to compute the aux state of
an image during the resolve operations at the end of a render
(sub)pass.
If we're dealing with a multisampled image that is created without a
transfer usage, our internal code might trigger a resolve using the
transfer layout (see genX_cmd_buffer.c:cmd_buffer_end_subpass), for
which the image doesn't the usage bit. The current code tries to AND
the 2 usages which won't have any bit in common, thus skipping all
checks below.
v2: Add the transfer usages depending on attachment usage (Lionel)
v3: Limit to samples > 1 (Jason) && DEPTH_STENCIL_ATTACHMENT_BIT (Lionel)
v4: Add transfer usage at image creation (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 54b525caf0 ("anv: Rework anv_layout_to_aux_state")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4037
Reviewed-by: Reviewed-by: Tapani Pälli <tapani.palli@intel.com> (v1)
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8307>
SpvOpAtomicLoad and SpvOpAtomicStore are translated into
nir_intrinsic_image_deref_store/load instead of some separate
atomic intrinsics, however they don't have src or dest type
specified. Turnip doesn't support shaderImageFloat32Atomics
so type is just integer.
Fixes:
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.image.guard_local.image.frag
dEQP-VK.memory_model.message_passing.core11.u32.coherent.fence_fence.atomicwrite.workgroup.payload_local.buffer.guard_local.image.comp
dEQP-VK.memory_model.write_after_read.core11.u32.coherent.fence_fence.atomicwrite.device.payload_local.buffer.guard_local.image.comp
dEQP-VK.memory_model.write_after_read.core11.u32.coherent.fence_fence.atomicwrite.workgroup.payload_local.image.guard_local.image.comp
dEQP-VK.memory_model.write_after_read.core11.u32.coherent.fence_fence.atomicwrite.workgroup.payload_nonlocal.workgroup.guard_local.image.comp
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8476>
The tgsi.rst was not very clear but didn't indicate that they were
supported, and llvmpipe only supported double abs and not negate.
glsl_to_tgsi never generated them, and neither did the new nir_to_tgsi, so
just garbage collect it.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8369>
tgsi.rst says it's not supported, and llvmpipe, r600, and virgl don't
support it. Make sure nobody else introduces them like I did while
testing only on softpipe.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8369>
While tgsi_exec.c (softpipe) implemented 32b integer src mods, the
tgsi.rst documentation says only 32b negate is supported and not abs.
llvmpipe implemented 32 and 64 negate but not abs, virgl implemented
negate incorrectly, and r600 apparently doesn't do any integer src mods.
glsl_to_tgsi has apparently never generated integer src mods.
Given that r600 can't do any integer src mods, just stop trying to
generate them for TGSI.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8369>
It's unsupported, but gets set unconditionally by the state tracker,
even when fbfetch is to be used.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8461>
* struct shader_info provides a 32bit mask for textures_used
* samplers and samplerviews are a 1:1 mapping for shader descriptors
* also according to spec this is always 32 per stage
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8457>
