In general, the debug flags are served once per proc invocation. So we
can make panvk debug flags global and clean up the existing codes in the
next change. Meanwhile, this changes improves branch prediction on user
builds and logs the enabled debug options when startup is used.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37752>
Android has to enable dumping globally. There's no per app based env
var at runtime since most apps just fork from Zygote process. So we have
to add process name to the dump file name. Now with pandecode.dump as
the base name, it'll be like below on Android:
- pandecode.dump.com.example.VkCube.ctx-*
- pandecode.dump.com.google.android.apps.nexuslauncher.ctx-*
This can be generally useful on Linux as well when debugging different
things to avoid accidentally touching existing dumps.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37729>
This avoids native crash on Android when system priviledged process is
involved during app launch animation but does not have specified storage
access (e.g. system_server can't access the common location /sdcard/*).
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37729>
The host copy logic doesn't support unpacking/packing D24X8, and if we
were to support it, it would be inefficient because of the non-32-bit
alignment. Given host copy is not a thing on AFBC resources, and given
the Z24_UNORM_PACKED is mostly beneficial to AFBC(Z) resources, let's
restrict its use to this case only and use Z24X8 otherwise.
Fixes: a620f33b7c ("panvk: Add planar Z24S8 support")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37473>
We need to split dual-aspect copies into separate copies.
Fixes: a620f33b7c ("panvk: Add planar Z24S8 support")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Tested-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37473>
Switch cases should align with the switch() statement.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Tested-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37473>
Without this, somebody trying to map a buffer for write by the CPU would
fail. This is not common to do in hardware driver environments, but it
shouldn't be disallowed, and there's no downside to allowing it.
I did skip virgl, because that's one where I don't know for sure if there
wouldn't be a downside to allowing RDWR (there are other virt exports
where RDWR is gated on a mappable flag).
This is a follow-up to !37088 to keep copy and paste from introducing the
same bug anywhere else.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37339>
This reduces duplication: we only need to distinguish between Windows
and Unix in one place.
The previous code was inconsistent about using either the `platforms`
option, or the `host_machine`. Following the logic described in
commit 94379377 "lavapipe: build "Windows" check should use the host machine, not the `platforms` option.",
I've assumed that checking the host machine is the more-correct version
and used that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37576>
This consistently uses `NAME.dll` on Windows, `libNAME.dylib` on Darwin
derivatives such as macOS, and `libNAME.so` on Linux, *BSD and so on.
It's also consistent about using the local variable name `icd_file_name`
for this name in every Vulkan driver, which was already the case in many
but not all drivers.
Some of these drivers probably don't make sense (or don't work) on
Windows and/or macOS, but if this is kept consistent for all drivers,
it should avoid the need for driver-specific commits like
commit 611e9f29e "lavapipe: fix icd generation for windows",
commit 951f3287 "lavapipe: set empty dll prefix",
commit 13e7a39f "lavapipe: fixes for macOS support",
commit 7008e655 "radv: Update JSON generator if Windows" and so on,
each time a driver is found to be relevant on more platforms than
previously believed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37576>
The JM backend logic is not ready for that yet.
Fixes: f04dbf0bc0 ("pan/kmod: query and cache available context priorities from KMD")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37480>
panvk_draw_prepare_attributes() depends on VS descriptors sets being
up-to-date which implies calling cmd_prepare_shader_desc_tables()
before. panvk_draw_prepare_vs_copy_desc_job() depends on img_attrib_table,
which can be set in panvk_draw_prepare_vs_attributes().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37501>
We can't use shader->info.stage here because it is only initialized in
pan_shader_compile, which is called after nir_lower_descriptors. This
causes us to miss the index adjustment to make room for the varying
attributes when LD_VAR_BUF is disabled.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Fixes: 7b949dd8c4 ("panvk: Use LD_VAR_BUF[_IMM] when possible")
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37471>
Bind queue is a queue of sparse resource memory bind operations.
It binds memory to sparse resources. It doesn't map to any
particular kernel object. The queue is equipped with an internal
syncobj to implement PANVK_DEBUG=sync.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35287>
Sparse resources (buffers and images) own their address ranges, so
when creating a sparse resource we allocate an address range large
enough to fit the resource. The address range has to start and end
at page boundaries, as that's the memory mapping granularity.
At destruction time, we unmap all memory mapped within the range,
as Vulkan doesn't require the user to unmap memory themselves and
we don't want to retain references to BOs for longer than
necessary. Finally, we free the address range that was previously
owned by the resource.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35287>
This flag is intended to be used by sparse resource creation. When
set, sparse resources will always start off mapped to blackhole,
regardless of whether they were created with SPARSE_RESIDENCY flag
set or not.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35287>
We want to be able to survive accesses to, from Vulkan's
perspective, unmapped regions of sparse resources. For that we
allocate a single page -sized bo, which we'll use to implement
sparse unmapping by mapping the address range to this bo.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35287>
Priority values will be used later one when creating job contexts.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ashley Smith <ashley.smith@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37075>
In the bi_emit_load_attr call site, we can use the imm_index value even
if the function returns false. The bifrost path handles this correctly.
Fixes: 652e1c2e13 ("pan/bi: Rework indices for attributes on Valhall")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37464>
Previously we were passing the original compile inputs, rather than the
variant-specific inputs. No actual bugs are caused by this because we
don't use the variant infrastructure for anything yet.
Fixes: ff9907927f ("panvk: Add basic infrastructure for shader variants")
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37463>
We do not support VK_EXT_shader_object so far but vk_shader layer
depends on those values so we should fill them.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37452>
We now set fb_fetch_output and fb_fetch_output_coherent to be consistent
with nir_lower_io.
This has no impact in general unless some generic pass depends on those
infos.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37452>
It does not look like our custom version has anything special to offer.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37421>
Advertise the extensions without VK_TIME_DOMAIN_DEVICE_KHR support is
not very useful.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37421>
To lower 64bit sources we emit a COLLECT -> SPLIT pair to force
allocation into consecutive registers. When the sources for COLLECT
are outputs of the same SPLIT already, we can omit the COLLECT + SPLIT
pair.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Aksel Hjerpbakk <aksel.hjerpbakk@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37398>
Use sequence-scoped clock (64 <= ID < 128) for GPU clock because there's
no central daemon emitting consistent snapshots for synchronization
between CPU and GPU clocks on behalf of renderstages and counters
producers.
When CPU clock is the same with the authoritative trace clock (normally
default to CLOCK_BOOTTIME), perfetto drops the non-monotonic snapshots
to ensure validity of the global source clock in the resolution graph.
When they are different, the clocks are marked invalid and the rest of
the clock syncs will fail during trace processing.
Now that PanVK has switched to use CLOCK_MONOTONIC_RAW CPU clock, here
we make the GPU clock sequence-scoped so that clock sync for all the
trace packets emitted with the same trusted_packet_sequence_id will be
done in an isolated manner (basically perfetto makes each scoped GPU
clock globally unique).
Meanwhile, since the clock is now sequence-scoped (unique per producer +
writer pair within the tracing session), we can simply pick 64 to start
with, and later extend to support multi-gpu (offset with primary minor).
Fixes: e278a89fdd ("panvk/perfetto: improve clock synchronization using CLOCK_MONOTONIC_RAW")
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37355>
VK_DEPENDENCY_ASYMMETRIC_EVENT_BIT_KHR makes vkCmdSetEvent2 behaves like
vkCmdSetEvent, let's handle that appropriately.
This fixes failures on VKCTS main with
"dEQP-VK.synchronization2.op.single_queue.event.*_maintenance9".
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Fixes: b8ccbc414a ("panvk: enable KHR_maintenance9")
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37396>
Those are new tests present on current VKCTS main and that are also part
of waivers.xml.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37396>
This might be a bit overly careful, but it seems like a good idea to use
both mechanisms to avoid accidental symbol leakage. I also don't think
it matters much in practice, because all sane applications use the the
Vulkan loader, and that shouldn't forward these symbols anyway.
While we're at it, let's wire up a test so we notice if this stops
working.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37371>
This allows us to avoid accidental feature regressions, by verifying
that the reality matches the expectations in CI.
This is inspired by a similar change in r300.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37363>
It allows us to use AFBC even if separateDepthStencilLayouts=true.
Unfortunately, AFBC(S8) is only supported on v9+, so we keep using
interleaved Z24S8 on earlier gens.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
panvk_image_can_use_afbc() doesn't know about depth/stencil format
lowering, and does the AFBC format check on the wrong format if planar
depth/stencil is enabled. Inline what we need from this helper in
panvk_image_can_use_mod(). Ultimately we should make it so that
panvk_image_can_use_afbc() uses panvk_image_can_use_mod() and not the
other way around.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
We're going to support Z24S8 planar images, but only on v9+. Let's
pass an image to panvk_plane_index() so we can extract the stencil
plane index from the number of planes instead of basing it only on the
format.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
We are about to use it at initialization time, so let's make sure it's
initialized as early as possible. We defer the initialization to a helper
because we will extend it to support planar Z24S8.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
Only works on Valhall for now.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37158>
