This broke after divergence became metadata because the divergence
analysis pass does not support all instructions.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35069>
This would unconditionally invalid all metadata except
nir_metadata_control_flow and then invalidate that if opt_if_safe_cf_list
and opt_if_regs_cf_list made no progress.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35069>
Only create nir_load_rt_arg_scratch_offset_amd if needed.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35069>
For 3-component RGB images with OPTIMAL tiling, we need to create the
surface as RGBX or RGBA. When a host image copy to/from this image
happens, we calculate sizes and offsets based on the 4-component surface
and blow past the end of the 3-component API provided buffer.
Hilarity^WSegfault ensues.
Ideally we'd calculate the right sizes and have the tiled copy functions
handle the conversion, but they are format unaware and expect to just
copy bytes in blocks of equal sizes from both sides.
Handle this case by making an intermediate copy to/from linear RGB
from/to linear RGBX, and pass that intermediate slice to the tiled copy
functions.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36453>
Per VUID-VkCopyImageToImageInfo-srcImage-09069,
srcImage and dstImage must have been created with identical image
creation parameters, so we are not going to have copies from color <->
depth/stencil, but we can copy both D/S aspects of an image at the same
time.
Nothing says that we can't copy from one plane of a multiplanar image to
another, so handle that case too (though nothing is currently testing
it).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36453>
Only if required. I somehow misunderstood that those would need to be
independent too, not just the vertex slots.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 8dee4813b0 ("brw: add ability to compute VUE map for separate tcs/tes")
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37251>
We had twice surface/sampler sources for no good reason, just add a
boolean to tell whether they are bindless or not.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37527>
One advantage here of moving a bunch of stuff to NIR is that we can
now have consistent payload types straight from the NIR conversion to
BRW.
This massively simplifies the BRW lowering code and avoids type errors
that are quite common to make in the backend.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37527>
Some versions of math.h exports rsqrtf() while others don't, so this
was causing compilation to fail when it is supported.
I have not found a easy way to detect if rsqrtf() is supported and
as this is only used in a llvmpipe tests it is not worthy do changes
in Meson files to detected if it is supported.
So here just renaming the Mesa function to _rsqrtf() and fixing the
build for both math.h versions.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13797
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12934
Reviewed-by: Roland Scheidegger <roland.scheidegger@broadcom.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37515>
Calculate the minimum available buffer age in addition to the maximum,
and if they differ for 1000 frames in a row, destroy the BO for the
highest-age unused buffer.
Without this, Wayland compositors using dynamic triple buffering always
get buffer age 3 once a third BO has been allocated.
v2:
* Rename function to destroy_oldest_unused_bo. (Marek Olšák)
* Move function call into if block.
* Use == instead of > as the condition for the function call.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37511>
When CPU clock is the same with the authoritative trace clock (normally
default to CLOCK_BOOTTIME), perfetto drops the non-monotonic snapshots
to ensure validity of the global source clock in the resolution graph.
When they are different, the clocks are marked invalid and the rest of
the clock syncs will fail during trace processing.
There's no central daemon emitting consistent snapshots for
synchronization between CPU and GPU clocks on behalf of renderstages and
counters producers. The sequence-scoped clock (64 <= ID < 128) is unique
per producer + writer pair within the tracing session.
Turnip is a bit tricky here, since clocks may be synchronized before
`tu_perfetto_end_submit` is called (in case of KGSL), but emission of
perfetto event has to happen on the same thread as other renderstage events.
To solve this I save the clocks in `tu_perfetto_state` and emit them in
`stage_end` when needed.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37465>
In short, perfetto doesn't require the initial clock snapshot to be
earlier than the timestamp to be converted. So we don't have to do
complex handling for it.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37465>
Instructions are allocated using a linear context so cannot themselves
be used as a ralloc context anymore. Use the variant's ir instead.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 114e6a3104 ("ir3: Use a linear allocation context for ir3_instructions.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37523>
- Removed DBG/CHICKEN regs from being stomped, because they randomly
cause issues, and there is no even point of stomping them.
- *ATTR_BUF_GMEM regs are not emitted at every renderpass.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37372>
The links in the console are broken depending on the console type; for example,
when it runs within a GitLab job. This can be improved using rich. But as we
have a dependency on colorama too, we can migrate all the coloring to use this
other library too.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37454>
Operands of an addition will be promoted to int making the a+b<a
kind of checks ineffective.
Use u_overflow.h helpers to perform the check correctly.
The commit would be simpler if it used __typeof__ like so:
util_add_check_overflow(__typeof__(src0), src0, src1)
But typeof only became a standard in C23 so this commit instead extends
nir_opcodes a bit to allow opcodes that need the dest_type to get it.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37331>
It defines a couple of helpers to deal with signed and unsigned
integers overflow.
If __builtin_add_overflow (and others) intrinics are available
they're used, otherwise overflow checks are done manually.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37331>
