if swapchain creation fails (e.g., insane cts swapchain configs), the
swapchain gets demoted to a non-window image that is still accessed by
the frontend. this image should not ever hit corresponding zink entrypoints
for swapchain-only images, which requires a flag to test swapchain-edness
cc: mesa-stable
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28904>
The front-page of the docs is currently fairly intimidating, by diving
into details rather abruptly. Let's try to make it a bit easier to
navigate t by moving the details to their own articles, but linking them
from the front-page.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28953>
This was a leftover. Flags can be different than 0, like for required
subgroup size and it should already be correctly supported.
Fixes recent dEQP-VK.shader_object.performance.dispatch_base.
Fixes: 37d7c2172b ("radv: add support for creating/destroying shader objects")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28946>
According to PAL, the hw uses the smaller value of
DB_Z_INFO.NUM_SAMPLES and PA_SC_AA_CONFIG.MSAA_EXPOSED_SAMPLES when
there is no bound depth/stencil buffer, and it uses 8x to make sure
the used value is MSAA_EXPOSED_SAMPLES.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28952>
With the previous commit, we now have new builder helpers that will
allocate a temporary destination for us. So we can eliminate a lot
of the temporary naming and declarations, and build up expressions.
In a number of cases here, the code was confusingly mixing D-type
addresses with UD-immediates, or expecting a UD destination. But the
underlying values should always be positive anyway. To accomodate the
type inference restriction that the base types much match, we switch
these over to be purely UD calculations. It's cleaner to do so anyway.
Compared to the old code, this may in some cases allocate additional
temporary registers for subexpressions.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28957>
In many cases, we calculate an expression by generating a series of
instructions. We'd either overwrite the same register repeatedly,
or call vgrf(BRW_TYPE_X) repeatedly to allocate temporaries for each
intermediate step. In many cases, we overwrote the same register simply
because allocating and naming temporaries for each step was annoying.
This commit adds new builder helpers that will allocate a temporary
destination for you, using simple type interference: unary operations
use the source type, and binary operations require a matching base type
and return the largest of the two types.
The helpers return the destination register, allowing us to write in an
expression-tree style, chaining together builder operations to produce
whole values. Sort of like nir_builder. We still optionally will write
out the fs_inst pointer in case the caller wants to do things like set
predicates or saturation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28957>
Some instructions can operate on mixed types. Typically this is
something like a binary operation with UD and UW sources resulting
in a UD destination. In order to make it easier to find the result
type of such operations, let's make a type helper that returns the
larger of the two types (but requires the base type to match).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28957>
We just want to emit an instruction, but we don't need to do anything
further with it, so we don't need to store the resulting inst pointer
anywhere.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28957>
load_uniform does not have io_semantics and component.
Fixes: a83fd26 ("nir/print: stop trying to match i/o vars using base/driver_location")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28962>
This way we don't have to constantly copy the full thing at kernel
creation time lowering CPU overhead significantly.
With the previous changes clCreateKernel is basically for free.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28872>
We do not support it at runtime anyway and assert on them to be unique
across devices at build time. This significantly reduces overhead of
clCreateKernel as this is something applications actually rely on being
fast.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28872>
fsign's result can be +0.0 or -0.0 for -0.0. We already calculate
the signed zero, it's even faster to replace the fmul(fsign(x), ...) with ior.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28938>
If the primary core is a GPU, but a separate NPU exists, collect
NPU specs in addition to GPU specs.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28921>
Add a separate pipe for the NPU device when the primary device is a GPU.
In case of compute-only contexts, prefer to use the separate NPU pipe.
This allows to create a compute-only context that uses the NPU pipe on
a screen that has a 3D GPU as primary device.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28921>
Allow to pass both gpu and npu to etna_screen_create() separately,
in preparetion for devices with both 3D GPU and NPU.
Iterate over all cores or until both GPU and NPU are found.
If no 3D GPU was found, screen->gpu will be set to the npu as well,
so nothing changes for NPU-only devices.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28921>
Calling etna_gpu_new() with a nonexisting core can happen when iterating
all cores. Bail immediately if querying the model failed, there is no
use in also failing to query the revision.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28921>
The -ENXIO return value isn't necessarily an error condition.
When iterating over cores, this signals that there are no more
cores to be found.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28921>
For early error returns, all pipeline handles have to be destroyed.
Otherwise the caller will treat those valid handles as successfully
created pipeline objects.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28944>
With explicit sync, only if it wasn't done earlier for FIFO.
Prevents potentially unbounded memory usage for (wl_buffer.release
events in) the queue, since we don't dispatch the queue anywhere else
with explicit sync.
v2:
* Use wl_display_dispatch_queue_pending instead of
wl_display_dispatch_queue_timeout. (Sebastian Wick)
* Call it from wsi_wl_swapchain_queue_present instead of
wsi_wl_swapchain_acquire_next_image_explicit. (Joshua Ashton)
Fixes: 5f7a5a27ef ("wsi: Implement linux-drm-syncobj-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28874>
The constant-folding definition and comments say that it takes the high
16 bits of the first source and low 16 bits of the second source, but
actually it's the opposite. The algebraic optimization, which actually
happens and needs to be correct, was correct but the comment above it
was wrong.
Note that in the way we use it when lowering multiplications, the
ordering doesn't matter.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
In the future we will have many ALU instructions passing shared
registers to each other, and surrounding them each with moves to/from
shared registers will severely bloat the IR size coming out of NIR and
make more pointless work for copy propagation. Instead, do something
more like the ACO approach and allow values stored in the hash table to
be shared, and move the burden of emitting a mov to non-shared to
ir3_get_src(). We will then use ir3_get_src_shared() or
ir3_get_src_maybe_shared() as appropriate in cases where we can handle
shared registers or where we can handle both.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
Propagate shared-ness to the the source, and when creating an ALU
instruction with all scalar sources and the instruction is supported on
the scalar ALU, automatically make the destination scalar. This includes
MOV/COV.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
In addition to replacing existing no-longer-needed usage of the
readfirst macro, we will use this for other NIR ALU instructions that
need to materialize constants when they use the shared ALU.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
When we use the scalar ALU we will start inserting moves with different
API-level semantics from readInvocation() or readFirstInvocation(). We
need to distinguish between these moves and lowered readInvocation()
moves, to avoid unnecessarily keeping helper invocations alive when
inserting (eq).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>