We have to do some cleanup on v10+. Let's add a new hook to allow
per-arch batch cleanup procedures.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Will be needed for v10, so we can re-instantiate a context when an
unrecoverable error is reported on a group or VM.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
This will allow us to defer some CSF-specific initialization to
pan_csf.c, keeping pan_context.c job-frontend agnostic.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Looks like the alignment constraint is gone on v10...
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Will be useful for the cs_builder, where we have
and we don't want cs_alloc_ins() to be called more than once.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Heap management is completely different on CSF hardware, and the heap
buffer remain unused in that case. Make the tiler heap BO creation
conditional to reflect that.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
This way we allow JUMPs to be decoded when the decode function is
passed an indirect CS buffer that's called from a kernelmode queue.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Various improvements to the CS related definitions:
- make the field name consistent across all instructions using the same
pattern
- define missing fields,
- replace the CEU prefix by a CS prefix
- define enums where it makes sense
- re-order instruction definitions by IDs
- add missing instructions
While at it, extend decode_csf.c to support all known instructions.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
The code has already been patched to support v10, we just need to add
v10 to the version array when compiling per-arch files.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Panthor is a new kernel driver handling CSF-based GPUs. It's designed
around the new VM model where:
- VM management is all explicit (you get to choose where objects are
mapped in the GPU VA space)
- synchronization is explicit too (there's not BO_WAIT, and we don't
pass BOs around to serve as implicit deps)
We add a few panthor specific helpers (those exposed in panthor_kmod.h)
too:
- panthor_kmod_xxx_sync_point() are needed to make pan_kmod_bo_wait()
work with the new synchronization/VM model
- panthor_kmod_get_flush_id() is exposing the LATEST_FLUSH_ID register
- panthor_kmod_vm_handle() is providing a way to query the VM handle
attached to the pan_kmod_vm object (needed for a few panthor ioctls)
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Make sure we reject perfcnt users when the kernel driver is not panfrost.
We might decide to abstract perf counters at the kmod level at some
point, but we're not there yet.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Some GPU gens have variants impacting the GPU capabilities. Let the
kmod backend report a variant ID through a new
pan_kmod_dev_props::gpu_variant field, and patch the panfrost_model
logic to match both the gpu_id and the gpu_variant.
All existing entries are assumed to have no variant, hence the
gpu_variant field assigned to zero.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Rework the way we compute thread info to make it mostly GPU-agnostic
outside of the kmod backend.
The new logic is based on the following information extracted from
GPU registers:
- mximum number of threads per core
- maximum number ot threads per workgroup
- number of registers per core
If the GPU doesn't provide this information (registers are zero), we
pick the per-arch defaults we had in panfrost_max_thread_count().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
Panfrost kernel driver has been around long enough to bump the minimal
requirement to 1.1. This allows us to get rid of the texture_features
hack we had to cope with the absence of
DRM_PANFROST_PARAM_TEXTURE_FEATURES[0-3] kernel side.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Suggested-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
This flag reflects whether the backend should track the VM activity or
not. Needed if PAN_KMOD_VM_OP_MODE_DEFER_TO_NEXT_IDLE_POINT is used, so
we can insert proper dependencies on our VM operations.
Patch the gallium driver to set this flag at VM creation time since it
calls pan_kmod_vm_bind() with
mode=PAN_KMOD_VM_OP_MODE_DEFER_TO_NEXT_IDLE_POINT in the BO
destruction path.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358>
It makes no sense to store no_oneconst_limit in struct etna_inst as this
flag is not instruction specific. This is a flag that affects every instruction.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27887>
To make sure the compute shader BO is always part of the DGC execute
submission. This is more like a workaround but this ext is currently
only exposed for vkd3d-proton and it doesn't use indirect compute
pipeline binds.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27495>
vkCmdUpdatePipelineIndirectBufferNV() can be called on any queue
supporting transfer operations and it's not required to call it on the
same queue as DGC execute. This is very annoying if the compute shader
has scratch because it needs to be configured per queue.
The solution is to gather the maximum possible scratch size used by
indirect compute pipelines and use that to configure scratch.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27495>
They must be compatible and this allows us to remove some pipeline
references (useful for experimenting pipeline binds).
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27495>
This code uses cfg_t which we are going to rework a bit as part of
flattening the IR types. It is easier if it can see C++ types for now.
At the end we can change this back if needed.
To avoid casting and be consistent with existing structs,
use int for some offset parameters in the functions.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27866>
The compilers (brw and elk) static libraries depend only on
idep_nir_headers instead of idep_nir. This was done to
increase the parallelism in the build. One side effect is that
consumers of the compilers must depend on idep_nir themselves to
ensure nir symbols are resolved.
Various intel tools don't use NIR directly, so don't depend on it,
and only use a few functions of the compiler, that *mostly* don't
depend on linking NIR functions except for the case of nir_print_instr.
The current code adds a weak empty function to take its place in case
it is not linked. This is sort of a hack because if we change the
compiler in ways that use NIR differently, or we use different functions
of the compiler in the tools, we will end up having to add other
dummy definitions.
A better solution here (suggested by Dylan) is to add the idep_nir
to the list of dependencies of the compilers idep's. The static
libraries of the compilers still don't depend directly on NIR,
but any user of idep_compiler_* will get that dependency.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27865>
Instead of link_with, use meson dependency for the compilers. Will
be useful later to propagate some extra dependencies.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27865>
If monolithic shaders were inlined, there might not be a radv_shader
associated with some stages. Zero out the shader allocation info in that
case, the shader will get identified by hash instead.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27890>
We can have multiple swapchains, and we can also have retired swap chains
that can continue to deliver events briefly after being replaced. It's
helpful to have both a surface id and a per surface swapchain id.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27852>
PresentWait can still be called on a retired swapchain, and pilfering
the WSI surface can cause issues. To avoid retired swapchains
interfering with non-retired swapchain event queue, flag a swapchain as
retired instead and immediately return OUT_OF_DATE from acquire and
present.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27851>
Instead of coding our own polling function, use the (new) wayland
wl_display_dispatch_queue_timeout() function instead.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27851>
If we want to use the new wl_display_dispatch_queue_timeout function
in libwayland we lose the ability to drop the lock while we poll
and pick it up again to dispatch.
That would cause other waiters to potentially block past their
timeouts while waiting for the dispatching thread's timeout.
Prepare for this change now by dropping the lock for the entire
dispatch, and reacquiring the lock in the functions being dispatched.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27851>
We do own the lock if there's a timeout, and the code is written with that
in mind - but the comment seems to imply otherwise.
Drop it.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27851>
The stw_device and its screen are set up independently. It's possible
to have a device without a screen if the DLL is loaded but never
called into, since DllMain for PROCESS_ATTACH sets up the stw_device,
but the screen is initialized later on the first call to get pixel
formats. If the DLL is loaded and then unloaded, don't crash.
Cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27892>
