Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
u_gralloc will be initialized upon the initial vk_android_get_ugralloc.
v2: drop explicit gralloc init
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Per <hardware/hwvulkan.h>, the hw_device_t::close() function is called
upon driver unloading. The behavior has been like this since Android 10.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
Initialize u_gralloc once upon the initial init or get call. We'll skip
updating the backend drivers for this since most usages will be cleaned
up later.
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
...to avoid mixing up with type name and local returns from getter.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561>
I'm seeing crash reports from the wild where it's not necessarily clear why
something failed, and it'd be nice to have the PSO desc on the stack when
something failed. It ends up being fatal anyway (we don't gracefully drop
draw calls, and I don't think we should).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35614>
Technically this won't produce valid results, but it will at least compile and
will probably be good enough, which is better than where we are right now,
which is that shaders fail to validate.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35614>
u_blitter sets a viewport transform with depth range [-1,1], which is
outside the [0,1] range that is allowed by opengl.
The mali hardware docs state that setting the LOW_DEPTH_CLAMP register
outside of [0,1] is undefined behavior. We haven't observed any problems
with this so far, but better to fix it.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Fixes: 810135fb42 ("gallium/u_blitter: Fix depth.")
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35225>
We are reading accel header parameter those are updated by CS, so we
need to apply flushes to make L3 coherent with CS.
This fixes ray query tests on MTL:
- dEQP-VK.ray_query.*.serialization.*
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/35590>
The per-MRT blend enables are in RB_MRT_CONTROL regs, this field is a
bitmask of whether we need to read in the MRT's current color in order to
perform the blending/colormask/logicop.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34991>
There are currently two places where we have to handle values that are
logically 64b: 64b atomics and 64b global addresses. For the former, we
ingest the values as 64b from NIR, while the latter uses 2x32b values.
This commit makes things more consistent by using 64b NIR values for
global addresses as well.
Of course, we could also go the other way around and use 2x32b values
everywhere, which would make things consistent as well. Given that ir3
doesn't actually have 64b registers, and 64b values are represented by
collected 2x32b registers, this could actually make more sense.
In the end, both methods are mostly equivalent and it probably doesn't
matter too much one way or the other. However, the reason I have a
slight preference for ingesting things as 64b is that it allows us to
use more of the generic NIR intrinsics, which use 1-component values for
64b addresses or atomic values. This commit already makes
global_atomic(_swap)_ir3 obsolete and I'm planning to create generic
intrinsics to support ldg.a/stg.a as well.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
This implements the common pattern of splitting-off a scalar value from
a vector. It handles both 64b (via ir3_64b) and normal register scalars.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
64b values occupy 2 registers but we receive them as a single component
value from NIR. Since there are many places that assume a 1:1
relationship between components and instructions, this can be error
prone as we have to remember to double the number of components whenever
a 64b value is involved.
This commit tries to improve on this situation by representing 64b
values as a collect of 2 registers, restoring the 1:1 mapping between
NIR components and ir3 instructions. This commit only adds some helpers
to create 64b values and access their individual components but doesn't
actually use them yet. This will happen in a follow-up commit.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
When creating a collect with a source that is itself a collect, flatten
the latter's sources into the new collect. This is mainly useful for
collects used for 64b values, as we can treat them just like non-64b
values when collecting them.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
We want to start lowering certain NIR instructions to collects (e.g.,
instructions with a 64b def) which means that ir3_get_src_shared has to
support collects. Since we can't mov the result of a collect, implement
this by converting its sources and creating a new collect.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
The HW specifications require the size of shader resource tables to be a
multiple of 4, otherwise correct behaviour is not guaranteed.
Fixes: 713f5c3600 ("panvk: Prepare the cmd_desc_state logic for Valhall")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35553>
Fixes the following test on GC7000:
- dEQP-GLES3.functional.shaders.texture_functions.texture.sampler2darrayshadow_vertex
- dEQP-GLES3.functional.shaders.texture_functions.texturelod.sampler2dshadow_vertex
- dEQP-GLES3.functional.shaders.texture_functions.texturelod.sampler2dshadow_fragment
- dEQP-GLES3.functional.shaders.texture_functions.textureprojlod.sampler2dshadow_vertex
- dEQP-GLES3.functional.shaders.texture_functions.textureprojlod.sampler2dshadow_fragment
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/35600>
When running `ffmpeg -vaapi_device /dev/dri/renderD128 -f lavfi -i smptebars=duration=5:size=1280x720:rate=30 -vf format=rgba,hwupload,scale_vaapi=format=nv12,hwdownload testout.mp4`,
the vpe is asked to transform into NV12, which cannot be done with a blit. `si_vpe_construct_blt` fails, but then it gracefully falls back into `vlVaPostProcCompositor` and finishes the task correctly, but not before logging the error:
SIVPE ERROR ../mesa-25.1.3/src/gallium/drivers/radeonsi/si_vpe.c:1095 si_vpe_construct_blt Failed in checking process operation and build settings(9)
for each frame that is processed. Since this is expected, my original thought was to demote this to a warning. But looking at all the reasons it could fail for, there already is a warning (or error) logged, so it seems to me the best thing to do is remove the error entirely
There may be a better approach here, and I'm all ears.
Fixes: e85a6b6a63 ("radeonsi/vpe: check reduction ratio")
Reviewed-by: Peyton Lee <peytolee@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35449>
