When using `MESA_LOADER_DRIVER_OVERRIDE=v3d` in real hw, use kmsro to
create the drm screen, which is actually what happens when not exporting
such variable.
This avoids confusions when using the envvar in real hardware and starts
to fail.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26007>
The spec says
A VkRenderPass or VkPipelineLayout object passed as a parameter to
create another object is not further accessed by that object after the
duration of the command it is passed into.
The object could have been destroyed if we get the pointer from a
pipeline library. Since it has no user now, let's remove it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26000>
If application requests to map surface that was most recently used
as decoder or postproc target and also doesn't explicitly set the
map flags (vaMapBuffer2) it's very likely the intent is to read from
this surface, so we need to map it as such.
This fixes regression on radeonsi where mapping NV12 surfaces for
reading would fail with applications using vaDeriveImage. The reason
for this is that the VA frontend doesn't allow vaDeriveImage for
interlaced surfaces so the applications would use vaGetImage fallback,
but radeonsi doesn't allocate NV12 surfaces as interlaced anymore.
This also fixes mapping other formats surfaces (P010, RGBx, ...)
for reading, which never worked before.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9935
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10048
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26008>
Previosuly when lowering to txd for sampler array the index would be
derived as well, therefore the resulting derivative would have been a
vec with one more component than what the txd instruction expects.
This patch truncates the coordinate vector in this case to make sure the
index is not derived.
Fixes: b154a4154b ("nir/lower_tex: rewrite tex/txb -> txd/txl before saturating srcs")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26012>
To get MacOS to build, some extra dependencies need to be added to a couple of build targets.
This mainly shows up when not installing the dependencies in the default prefix locations.
On MacOS, this happens when using a custom build of brew to install the dependencies to 'odd' locations.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26022>
I've repeatedly seen minor pixel changes due to changes that only affect
RA decisions, most recently in !22072. We changed the trace to hopefully
remove a use of texture() in control flow, but it seems there are more,
or the problem is something slightly different like reading
uninitialized values. On the other hand minetest has never actually
caught an issue for me that some other trace hasn't also caught. Just
remove it.
Cc: mesa-stable
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25864>
An "augmented tree" is a tree with extra data attached which flows from
the leaves to the root. An "interval tree" is a datastructure of
(potentially-overlapping) intervals where, in addition to inserting and
removing intervals, we can quickly lookup all the intervals which
overlap a given interval.
After describing red-black trees, CLRS explains how it's possible to
implement an interval tree using an augmented red-black tree where the
nodes are ordered by interval start and each node also stores the
maximum interval end for its entire subtree.
Implement the interval tree extension described by CLRS. Iterating over
all overlapping intervals is actually an exercise, so we have to solve
the exercise. The recursive solution has been re-written to use the
parent pointers to avoid needing a stack, similarly to rb_tree_first()
and rb_node_next().
For now, we only implement unsigned intervals, but the core algorithms
are all abstracted to allow other types. There's still some boilerplate,
but it's the best that can be done in C.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22071>
The changes are pretty straightforward. For vector splitting, we just
ignore those vectors for now. We could potentially handle array derefs
with a constant index (and probably should) but that's left for later.
For now, I'm mostly concerned with correctness of the pass.
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22580>
If we're propagating a copy from a cast where the copy copies an entire
array, we end up with something like &((S *)ssa_N)->f[*] in the source
where a wildcard has a cast in its parent chain. If we then try to
propagate the read into a non-wildcard array load, we have to specialize
the wildcard. This breaks because nir_build_deref_follower() doesn't
handle casts. Since we know a priori that, because wildcards are only
generated by copy_deref on arrays, we cannot have a cast with a wildcard
parent so simply chasing the source deref to the first wildcard will
ensure that any casts in the deref are handled properly.
Fixes: ba2bd20f87 ("nir: Rework opt_copy_prop_vars to use deref instructions")
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22580>
To get MacOS to build, some extra dependencies need to be added to a couple of build targets.
This mainly shows up when not installing the dependencies in the default prefix locations.
On MacOS, this happens when using a custom build of brew to install the dependencies to 'odd' locations.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25992>