Changelog:
- Correct typo in generator name which is sfn_nir_algebraic.py
- Rename variables for the gen rules according to meson rules
- Align python command and options according to meson rules
Fixes the following building error:
FAILED: ninja: 'external/mesa/src/gallium/drivers/r600/sfn/r600_nir_algebraic.py',
needed by 'out/target/product/x86_64/gen/STATIC_LIBRARIES/libmesa_pipe_r600_intermediates/sfn_nir_algebraic.c',
missing and no known rule to make it
Fixes: 195952786b ("r600/sfn: Add algebraic lowering for fsin and fcos")
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9766>
It's not just flat-shading that matters in the case of fragment outputs.
Let's play nicely and emit any interpolation mode instead.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9775>
We actually need to set all of these for fragment inputs as well, so
let's make a helper for this that we can reuse.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9775>
I forgot that this was a reachable case pre-tc, but if there's no longer
a record of a batch_id then that just means it completed in the distant
past
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9772>
All other call sites of stw_pixelformat_get_info pass iPixelFormat as-is,
and stw_pixelformat_get_info also subtracts one internally, so I think
this was just an error.
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9760>
for e.g., R8G8B8X8 -> R8G8B8A8, we have to force a u_blitter call in order to use
a sampler which ignores alpha, otherwise we end up with broken rendering
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9607>
I didn't ever have a driver to test on which could handle multisampled shader
images while writing this, but need to actually pass the sample id here
Fixes: 9cd2aff1a3 ("zink: add handling for all basic image ops in ntv")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9724>
image operands are ordered by their operand's spirv value, meaning that
the availability operands need to go last here
Fixes: 882ab6afb7 ("zink: add spirv builder functions for image ops")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9724>
these are effectively managed by the fence, so it makes sense to store
them there
the set is ralloc-allocated, so explicitly destroying it isn't needed
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9753>
the builtin lowering can't handle dynamic array indexing, so this requires
that all indirect derefs be lowered any time this pass is invoked in order
to avoid crashing
fixes#4132
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9741>
this is a special version of indirect deref lowering which is used by
mesa/st to remove dynamic indexing from builtin uniforms for the lowering
pass in non-packed uniform case
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9741>
vk spec disallows mapping memory regions more than once, but we always
map the full memory range, so we can just refcount and store the pointer
onto the resource object for reuse to avoid issues here
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9725>
From the GLES 3.2 spec:
"If the source formats are integer types or stencil values, a single
sample’s value is selected for each pixel. If the source formats are
floating-point or normalized types, the sample values for each pixel are
resolved in an implementation-dependent manner. If the source formats are
depth values, sample values are resolved in an implementation-dependent
manner where the result will be between the minimum and maximum depth
values in the pixel."
For Z24S8 we were doing an average, which would be invalid for the stencil
data, and apparently the CTS didn't catch that. For Z32F, our averaging
was technically legal, but given the Vulkan spec's requirement of sample 0
support but not sample average support for depth and stencil resolves, it
suggests that our averaging behavior was unusual. Let's not spend power
on producing surprising results.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9661>
max_waves is just for shader-db stats for now, but threadsize will
replace the various mechanisms used to determine threadsize across the
different gen's. Calculating these correctly entails adding a bunch of
details about the sizes of various things to ir3. In the future we will
use the guts of the max_waves calculation to inform RA decisions as
well, which is why the max_waves calculation is broken up into register
dependent/independent pieces.
Something should be said about the units of reg_size_vec4. These units
were chosen for two reasons:
1. As said in the comment, it makes some calculations easier.
2. For a4xx/a5xx, where we don't know as much because we haven't done
the same sorts of experiments to probe for the HW configuration, it
corresponds more directly to things that are known. The existing code
switches to the smaller threadsize when r24.x or higher is used,
which translates directly to a reg_size_vec4 of 48. If we chose
different units (e.g. multiplying by wave_granularity and/or
threadsize_base), then to match the same behavior we'd have to set
reg_size_vec4 based on some other parameters that aren't 100% known.
If someone comes along and updates them, they might inadvertantly
break it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9498>
