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>
Adapt gen_pack.py to generate an OpenCL compatible header, capable of both
packing and unpacking but not printing (due to no known use case and no fprintf
in CL). This is useful as a building block for manipulating descriptors from
shader code, for example in texture lowering or device-generated commands.
To accomplish this, we need to inline in some CL-compatible variants of mesa
util functions (no doubles, etc), avoid FILE * use in the CL path, and use
__constant pointers where applicable for performance. Otherwise, there are
surprisingly few changes required, thanks mainly to CL 2.0 generic pointers.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25498>
The loop is supposed to execute exactly once, but the previous logic
inadvertently executes 0 or 1 times depending on whether dst is NULL (it never
is). Reexpress the loop to execute exactly once, eliminating the unnecessary
branch in this hot path. Noticed when reading the NIR of generated pack code.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25498>
This will clean up genxml unpack code and is needed for parity with the assembly
we write by hand. This way we get the win for all shaders.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25498>
for buffer textures, we insert new blocks which invalidates dominance and
block index info... leads to end-to-end fails when shuffling pass order.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25498>
