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>
This test consistently fails on some GPUs (already documented) but on
some others it's a flake. It's a known issue that should be fixed soon
in RADV.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26019>
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>
This makes it consistent with glsl_get_array_element() which returns the
scalar type for vectors, column type for matrices, and array element
type for arrays.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22580>
We assumed that calling it on vectors would return 0 and then did a
MAX2(length, 1) to get 1 for vectors. Instead, use a ternary so we
don't make assumptions about non-sensical values.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22580>
Checking for whether or not it's a plain vector is actually what we want
anyway. There's no point in handling arays of length 1.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22580>
Instead, check if it's a vector or scalar and use 1 explicitly. In FS
output case where we were only using it assert we don't have any arrays,
assert that directly.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22580>
Also, leave a big comment about why we're inserting movs and not just
propagating SSA values directly. Hopefully this will prevent idiots
like me from getting clever and thinking they can delete that mov. 😅
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-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>
Otherwise there's no way to target PIPE_FORMAT_B4G4R4A4_UNORM instead
of the B5G6R5 or B5G5R5A1 if those are supported. This gets the behavior
closer to the Windows PFD selection.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25979>
The combination of defines used when compile the code on MacOS is hiding variables.
Patch allows basic MacOS build to compile and run.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25992>
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>
MacOS does not have the libdrm libraries so is missing xf86drm.h.
util/libdrm.h already has a collection of stubs for systems that do not support the libraries.
A compile on MacOS will fail with the source that uses newer drm functions and structures.
Update adds in missing items that MacOS code needs to compile and run.
New code is copied from the public repository: https://gitlab.freedesktop.org/mesa/drm/-/blob/main/xf86drm.h
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25992>
Fixes compilation of a Talos Principle 2 shader.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Fixes: 9fa9782c17 ("radv: stop compiling a noop FS when the application doesn't provide a FS")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25659>
nir_lower_io_arrays_to_elements does not support array derefs of vectors,
even when nir_deref_instr_is_known_out_of_bounds is fixed.
They can occur with mesh shaders.
Found by inspection.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25659>
