This makes lavapipe act like other DRM drivers whenever we have udmabuf
and just make everything a dma-buf even if it doesn't strictly have to
be. Without this we can end up in weird cases if the client asks to
allocate a memory object with multiple export types. Before, if this
happened, we would allocate a memfd and then return that when the client
calls GetMemoryFd() even if they asked for a dma-buf. In theory, we
could add additional plumbing to allow for using the memfd itself for
OPAQUE_FD and only wrap in a udmabuf if DMA_BUF is requested but this is
simpler and more in line with what hardware DRM drivers do.
Fixes: c1657de63c ("lavapipe: support VK_EXTERNAL_MEMORY_HANDLE_TYPE_DMA_BUF_BIT_EXT")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13798
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37067>
(cherry picked from commit 31f0d0732e)
If implementation does not actually replay the VA, it must return 0
to not violate:
"If the memory object was allocated with a non-zero value of
opaqueCaptureAddress, the return value must be the same address."
Fixes RenderDoc capture replay, which asserts on the this spec rule
being followed.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: ed6d5c33 ("nvk: Implement VK_EXT/KHR_buffer_device_address")
Reviewed-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Closes#13784
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37047>
(cherry picked from commit 6fbe2be7a7)
Fix the following warning, and others that are similar, as rustc
suggests:
warning: hiding a lifetime that's elided elsewhere is confusing
--> ../src/gallium/frontends/rusticl/mesa/compiler/nir.rs:282:22
|
282 | pub fn variables(&mut self) -> ExecListIter<nir_variable> {
| ^^^^^^^^^ -------------------------- the same lifetime is hidden here
| |
| the lifetime is elided here
= help: the same lifetime is referred to in inconsistent ways, making the signature confusing
= note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
help: use `'_` for type paths
|
282 | pub fn variables(&mut self) -> ExecListIter<'_, nir_variable> {
| +++
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37059>
(cherry picked from commit 0e6b24451d)
The problem with the current code is that there is a disconnect between :
- the virtual register size allocated
- the dispatch size
- the size_written value
Only the last 2 are in sync and this confuses the spiller that only
looks at the destination register allocation & dispatch size to figure
out how much to spill.
The solution in this change is to make BROADCAST more like
MOV_INDIRECT, so that you can do a BROADCAST(8) that actually reads a
SIMD32 register. We put the size of the register read into src2.
Now the spiller sees correct read/write sizes just looking at the
destination register & dispatch size.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 662339a2ff ("brw/build: Use SIMD8 temporaries in emit_uniformize")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13614
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36564>
(cherry picked from commit 93996c07e2)
Initialization of driver has been moved to register_data_source() from
OnSetup() by: a739889789 ("pps: Report available counters when
gpu.counters* data source is registered")
With above change, pps will destroy driver when collecting data stops
(pps may keep running) then the driver will become nullptr when user try
to collect data again. This will cause segmentation fault in OnSetup().
So this remove driver = nullptr in OnStop() and init driver in OnSetup()
to make sure driver exists when pps-producer run more than once.
Fixes: a739889789 ("pps: Report available counters when gpu.counters*
data source is registered")
Signed-off-by: Julia Zhang <Julia.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36548>
(cherry picked from commit 20b809f1f0)
The previous algorithm just looked at the dominator's loop header.
However, if you have multiple consecutive loops like:
function_impl {
loop {
// Stuff
}
loop {
// Other stuff
}
}
then it will look like the second loop is contained in the first loop
because the first loop's header dominates the second loop. This isn't
actually what we want. Instead, we want a node N to be considered part
of a loop with header H if H dominates N and H is reachable from N.
Fixes: 741f7067f1 ("nak: Add loop detection to the CFG")
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36524>
(cherry picked from commit a1d5e8bfdb)
Also add a #define NAK_QMD_ALIGN_B for alignments. The alignment is
always 256B and there's no evidence of that changing.
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Backport-to: 25.2
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36995>
(cherry picked from commit 02ef6a5158)
It turns out that the `occlusion_query.syncobj` is used to set
state that later code relies on, and setting it to NULL causes
some Vulkan CTS tests to fail. Instead, we should explicitly check
for the mode being `MALI_OCCLUSION_MODE_DISABLED` to avoid using
an invalid `ptr` field.
Fixes: 24c692c981 ("panvk: fix a NULL pointer dereference in occlusion queries")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36794>
(cherry picked from commit 9b4eb81162)
When using formats with less than 32-bits per pixel, we pad the
tile-buffer to a multiple of 32-bits so we can store additional bits
used by dithering.
Account for this when computing the max MSAA setting.
Fixes: 329568b5eb ("panfrost: add color-attachment and msaa helpers")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35755>
(cherry picked from commit 6a83193771)
Right now, we store the last VkDeviceMemory object bound to an image in
panvk_image::mem, but this doesn't work for disjoint images where the mem
object can differ on each plane.
Move panvk_image::mem to panvk_image_plane::mem and prefix the offset
field with mem_, so it's clear the offset refers to the mem object.
Note this should only fix host copy on disjoint images, since the GPU
address was already properly set at bind time.
Fixes: 1cd61ee948 ("panvk: implement VK_EXT_host_image_copy for linear color images")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36926>
(cherry picked from commit d0126f5ced)
The actual number of samples chosen is allowed to equal the number
requested, but currently we just check for sample counts greater
than the request.
Fixes: 894b37e060 ("mesa: fix sample count handling for MSRTT")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36878>
(cherry picked from commit 095d1b6bcc)
Those are for push constants, no point in doing that because :
- there is no HW constant offsets in push constants (payload
delivery), it's just register offset calculation
- if we have an dynamic value it's already using MOV_INDIRECT
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: e103afe7be ("brw: run the nir_opt_offsets pass and set the maximum offset size")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36958>
(cherry picked from commit 27c69acb6a)
It's possible with GPL.
This fixes a NULL pointer dereference with updated pipeline binaries
tests in VKCTS.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36999>
(cherry picked from commit 944e26eae7)
FdMemoryDataSource was being registered as a Perfetto data source
unconditionally which led to anything calling fd_device_new(...)
attempting to do this even when they might not have Perfetto
initialized which is done as a part of util_perfetto_init, without
which trying to register the event causes a SEGFAULT.
Fixes: c7045e3e63 ("perfetto: unify init")
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36993>
(cherry picked from commit 098521559d)
According to the spec and as implemented by other drivers, this should
use the size of the buffer instead of the size of the VkDeviceMemory
it's bound to when VK_WHOLE_SIZE is specified or pSizes is NULL. The
current behavior doesn't make sense at all for sparse buffers which are
not bound to a single VkDeviceMemory. Just use the common helper that
already does the right thing, copied from anv.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533>
(cherry picked from commit 460ed35916)
We are reading out some of the parameters from IR data structure those
have been written previously, on some platforms L3 is not coherent, so
explicitly add those flushes.
Cc: mesa-stable
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36952>
(cherry picked from commit 2cd564c1de)
There is a FW issue when using constrained intra prediction with rate
control enabled, causing unexpected quality degradation.
Disable it until FW fix is available.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36837>
(cherry picked from commit 51d5c0d537)
Images aren't always coherent with L2 and AMD generations have
different rules, see radv_image_is_l2_coherent() for the full picture.
This fixes a rendering issue on GFX9 because depth/stencil images
aren't coherent, but this also affects color images.
This also fixes a cache coherency issue with an ongoing extension.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12274
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36815>
(cherry picked from commit 99b287bde5)
In some situations the implementation of `BITSET_EXTRACT` would read
beyond the size of the bitset due to an unconditional + 1 in the address
calculation.
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Fixes: 0cc9443e9b ("util: Add BITSET_EXTRACT")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34605>
(cherry picked from commit 922c3c53ce)
f2f640f35 introduces base variants, so we get 2 NIR shaders:
glsl-to-nir -> base_serialized_nir
-> serialized_nir
Then, depending on who is using the shader the right one would be picked:
* draw uses base_serialized_nir
* hw driver uses serialized_nir
ef0c9231a7 made sure that base wasn't used when the shader is loaded from
the cache because it's missing, so in this case, glsl-to-nir does:
glsl-to-nir -> from-cache -> serialized_nir
The problem is that if draw tries to use this shader it may fail, for
the same reason as the referenced commits were introduced: draw may not
be compatible with some NIR passes used by the driver.
To fix this we need to serialize both NIR shaders, and pick the right
one depending on the user.
Fixes: ef0c9231a7 ("mesa/st: don't use serialized_nir for cached shaders")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36411>
(cherry picked from commit 0e3ec9e82c)
