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>
I think amdgpu always supports multi wait since syncobj is just a
container of dma-fences. Fixes
Assertion `!(req_features & ~ttype->point_sync_type->features)' failed.
in vk_sync_timeline_type_validate on older kernels.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27838>
On older kernels without timeline syncobjs, the timeline and the submit
modes are VK_DEVICE_TIMELINE_MODE_EMULATED and
VK_QUEUE_SUBMIT_MODE_DEFERRED respectively. They are incompatible with
the sparse queue which requires VK_QUEUE_SUBMIT_MODE_THREADED.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27838>
The base class was used when we had vec4, but now we can fold it with
its only subclass. Declare fs_visitor now as a struct to be able to
forward declare for C code without causing errors due to class/struct
being mixed.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27861>
Found by inspection. Original code was returning the size instead of the
number of levels. This was probably an over zealous search-and-replace
when PIPE_CAP_MAX_TEXTURE_2D_LEVELS was changed to _SIZE.
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Fixes: 0c31fe9ee7 ("gallium: Redefine the max texture 2d cap from _LEVELS to _SIZE.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27800>
