Saves the lock/unlock to get the variants for VS/BS/FS programs, gives us
a place we could hang future linked program state, and gives us safe
constlen handling that fixes a couple of our piglits.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9698>
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>
Bas Nieuwenhuizen
Jesse Natalie
Eric Anholt
Mauro Rossi
Erik Faye-Lund
Mike Blumenkrantz
Tomeu Vizoso
Samuel Pitoiset
Jose Fonseca
Rob Clark
Kenneth Graunke