When the first attachment is assigned to a tile buffer, the buffer
alloc mask was not been updated. This means when a second attachment
is added to the same tile buffer it will be assigned the same offset
as the first which will lead to incorrect behaviour.
Fixes for depq-vk:
dEQP-VK.renderpasses.dynamic_rendering.complete_secondary_cmd_buff.suballocation.attachment.4.568
dEQP-VK.renderpasses.dynamic_rendering.complete_secondary_cmd_buff.dedicated_allocation.attachment.4.568
dEQP-VK.renderpasses.dynamic_rendering.primary_cmd_buff.suballocation.attachment.4.568
dEQP-VK.renderpasses.dynamic_rendering.primary_cmd_buff.dedicated_allocation.attachment.4.568
Fixes: a7de9dae6b ("pvr: Add routine for filling out usc_mrt_setup from dynamic rendering state")
Signed-off-by: Nick Hamilton <nick.hamilton@imgtec.com>
Acked-by: Frank Binns <frank.binns@imgtec.com>
(cherry picked from commit 96cfb1cb7f)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Do not assume that the application always provides images for backing
attachments. The app can provide a super set of attachments of which
only some are actually backed with images.
We want to filter-out attachments that aren't meaningful for rendering
or sampling, and create compiler resources only for relevant ones.
Fix assert in CTS:
pvr_arch_mrt.c:215: pvr_rogue_init_usc_mrt_setup: Assertion `att_format != VK_FORMAT_UNDEFINED' failed.
Seen in pipeline monolithic, for instance:
dEQP-VK.pipeline.monolithic.multisample.misc.dynamic_rendering.multi_renderpass.r8g8b8a8_unorm_r16g16b16a16_sfloat_r16g16b16a16_sint_d32_sfloat_s8_uint.random_127
Fixes: d549c1d045 ("pvr: add pipeline handling to use dynamic rendering info")
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Acked-by: Frank Binns <frank.binns@imgtec.com>
(cherry picked from commit 5473ca3be3)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Expose the routine in preperation for a later commit.
Backport-to: 26.0
Signed-off-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Acked-by: Frank Binns <frank.binns@imgtec.com>
(cherry picked from commit 6b0fea938b)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Use the valid/input coverage masks for tile buffer store coverage masks
when running single/multi-sampled fragment shaders respectively.
Fixes: 297a0c269a ("pvr, pco: tile buffer support")
Signed-off-by: Simon Perretta <simon.perretta@imgtec.com>
Reported-by: Nick Hamilton <nick.hamilton@imgtec.com>
Acked-by: Frank Binns <frank.binns@imgtec.com>
(cherry picked from commit 8eee60fa78)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
When destroying H264/5 decode context we check the profile from decoder to
free the H264/5 PPS/SPS objects, but decoder is only created when decoding
first frame so these objects will never get freed in case decoder is NULL.
Cc: mesa-stable
Reviewed-by: Benjamin Cheng <benjamin.cheng@amd.com>
(cherry picked from commit 5134d37e7d)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Dual source blending when one of the sources is not written to leaves
those values undefined, but the other should still be valid.
By omitting unwritten outputs, we ended up not writing anything at all
for the case that OUT1 is written to but OUT0 is undefined.
Fixes new CTS tests: dEQP-VK.pipeline.*.blend.dual_source.undefined_output.first*
Cc: mesa-stable
Signed-off-by: Iván Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
(cherry picked from commit fd556e54f6)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Dividing this by itself is nonsensical, and just always gives us one.
That's obviously not what we want here.
But in this case we also know that the extent is divisible by the tile
extent, so there's no need for DIV_ROUND_UP, we can just divide.
Fixes: e6f8cab698 ("pan/layout: Split the logic per modifier")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
(cherry picked from commit 5280b80281)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
We can't use the stencil-aspect of a color-attachment. That's going to
fail, so let's use the color-aspect instead. We already have it around
anyway.
Fixes: 7a763bb0a3 ("pan/genxml: Rework the RT/ZS emission logic")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
(cherry picked from commit 322aaa88c6)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
This is controlled by the writeback-mode when using AFRC, not by an YUV
Enable field. This Filed doesn't exist in these, and should according to
the spec be zero.
Fixes: 7a763bb0a3 ("pan/genxml: Rework the RT/ZS emission logic")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
(cherry picked from commit 15e0ac0731)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
This code path is usually used by lavapipe when importing dmabufs, not
for output.
The resulting size_required is then used to calculate the size
requirements for VkMemoryRequirements2 etc. Requiring a multiple of
LP_RASTER_BLOCK_SIZE - 4 - can eventually result in lavapipe rejecting
dmabuf imports.
An example is YUV420 at a resolution of 1680x1050 produced by Gstreamer
1.28 - e.g. from a screencasts. In this case we currently compute a size
of 3235840, while other drivers like radv compute 3225600. The actual
size is 3227648, fitting into the later but not the former.
Removing the alignment brings lavapipe in line with other drivers.
Cc: mesa-stable
Signed-off-by: Robert Mader <robert.mader@collabora.com>
(cherry picked from commit 0bbc26d2c4)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
The preprocessor symbol we want is `PAN_ARCH`, not `MALI_ARCH`.
Fixes: a21ee564e2 ("pan/bi: Make texel buffers use Attribute Buffers")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
(cherry picked from commit 3945421c17)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
We were computing some positions using `void*` rather than pointers to
the appropriate structures. This caused bad pointers, the effect of
which depended on the current memory environment -- tests related to
texel buffers could pass or not depending on what other tests had run
previously.
Fixes: a21ee564e2 ("pan/bi: Make texel buffers use Attribute Buffers")
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
(cherry picked from commit 0142e2e5e3)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
On Turing, the hardware rely on the viewport index for FSR.
If not all viewports are defined, we will end up not rendering
anything when selecting the primitive shading rate.
This patch makes it that we now broadcast the viewport and scissor 0
likes the proprietary driver.
This fixes "dEQP-VK.mesh_shader.ext.builtin.primitive_shading_rate_*" on
Turing.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Fixes: 2fb4aed9 ("nvk: Advertise VK_KHR_fragment_shading_rate")
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
(cherry picked from commit d00965651a)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
We are going to need to reuse those functions to fix FSR support on
Turing.
Signed-off-by: Mary Guillemard <mary@mary.zone>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Cc: mesa-stable
(cherry picked from commit 56e31d8145)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
The game uses glGetUniformLocation() but specifies the wrong program id
for one of the uniforms. The shader programs both contain shaders with
a uniform of the same name but because they have a different number of
uniforms the returned uniform location does not match the expected uniform.
Here we add a workaround to force the uniform with the wrong get location
params to always have the location 0 so that it doesn't matter which
shader the application checks for the location.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14864
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 09393b33b2)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Allows a uniform name to be passed to force_explicit_uniform_loc_zero
allowing us to set that uniform to an explicit location of zero.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 87ae5cab94)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
This sets the per-vertex point size state correctly in the presence of mesh shaders.
(fixes line is just a educated pick)
Fixes: 51d6e4404a ("mesa: allow NULL for vertex shader when mesh pipeline")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
(cherry picked from commit 5bfaf7536a)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
Currently the headless WSI unconditionally uses DRM images as WSI
images, which isn't proper behavior for working with lavapipe driver,
and leads to either error or crash (depending on whether udmabuf is
available).
Properly setup CPU images instead of DRM images for software-rendering
WSI devices.
This fixes (at least) `dEQP-VK.wsi.headless.swapchain.render.*` on
lavapipe.
Fixes: 90caf9bdbd ("vulkan/wsi/headless: drop the wsi_create_null_image_mem override")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
(cherry picked from commit 38cf1b3829)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40752>
st_texture_set_sampler_view() currently allows only one samplerview for
a given texobj per context. in a scenario where the same texobj is
bound multiple times with different samplerviews (e.g., SRGB) for the
same draw like
samplerviews[] = {view0, view1}
then st_texture_set_sampler_view() will release view0 while creating view1
before either view is actually set to the driver, and then the driver will explode
this is gross, but the best solution which avoids infinite memory ballooning
from bufferview offsets is to pass through the array of views during creation
to ensure that the cache doesn't try to prune a view it just created
caught by Left 4 Dead 2
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/15045
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
(cherry picked from commit 3264adf863)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40488>
We can produce a transposed value sometimes, and we have to make sure
that val->transposed is also updated when that happens.
Noticed by inspection after the previous commit.
Cc: mesa-stable
(cherry picked from commit c13bdaaa40)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40488>
Since the stack pointer may wrap around the stack size in overflow
cases, traversal logic calculates the real stack pointer with
nir_umod_imm(b, stack, args->stack_entries * args->stack_stride).
For ray queries, "stack" was initialized to
"stack_base + local_invocation_idx * 4". This was completely broken, as
the umod would later delete the stack base completely and overwrite the
start of LDS, which belongs to the apps' shared memory.
Instead, add the stack base as a constant offset in the load/store_stack
callback. (This should also save 1 VALU per ray query)
Also, delete radv_ray_traversal_args::stack_base since it's unused now.
Cc: mesa-stable
(cherry picked from commit b046eaf36d)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40488>
Vertex shaders shorter than four instructions can hard-lock R3xx GPUs.
This seems to happen in combination with a small vertex count. This was
seen before, most notably with dummy shaders, but the earlier fix only
removed those dummy shaders, so some occurrences could still slip
through the cracks. Pad all vertex shaders to four instructions on R3xx.
Reviewed-by: Filip Gawin <filip@gawin.net>
Fixes: c6aa639ba9 ("r300: skip draws instead of using a dummy vertex shader")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/337
(cherry picked from commit 9b12664b72)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40488>
