Unlike what the comment said here, V9 does in fact support a single
float-format, so let's allow that.
But also, V10 and later supports FP16 formats, but this incorrect check
made that not work. Enable the FP16 formats also while we're at it. We
don't need any additional checks here, because the 16-bit unorm formats
were also added in V10, so util_format_any_to_unorm() does the right
thing here.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38848>
There's no reason why the S8_UINT check should be written in a different
way than the other checks here; let's make this consistent.
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Tested-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38848>
nir_lower_clip_cull_distance_array_vars was sneakily updating
shader_info::clip/cull_distance_array_size.
This moves the gathering into a new function
nir_gather_clip_cull_distance_sizes_from_vars.
v2: remove assertions that prevented nir_lower_clip_cull_distance_array_vars
from being used with non-compact arrays
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38465>
Metal will prematurely discard fragments with side effects even if those
side effects happen before the discard. Work around this by making said
discards "optional".
Reviewed-by: Arcady Goldmints-Orlov <arcady@lunarg.com>
Signed-off-by: Aitor Camacho <aitor@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38741>
Consolidate importing paths by using the new importing
function so that compressed buffer can be imported
correctly.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36825>
The helper gets tiling and modifier in a single step.
The later will be used in the coming changes.
Copy the changes introduced in
cf5c294df4.
Suggested-by: Juston Li <justonli@google.com>
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36825>
As discussed in the reviews of cf5c294df4,
the 'plane' in this context means plane of a drm
modifier, so it makes sense to just use the new ISL
macro once it is available.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36825>
The new added function will be invoked on several paths
of importing Android native and hardware buffers.
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36825>
This test was hitting an assert because gl_PrimitiveID is an input to the
FS that does not come from the VS which should be handled similar to
TGSI_SEMANTIC_FACE.
Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38834>
I was wondering where this was disappearing to.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38789>
I'm assuming this based off the `if` branch above, after reading the
code for bit that Coverity pointed out in that branch. It doesn't look
correct to start at the base pointer, which will be 0 initialized and
has 52 bits of zero padding, while the default values are 255.
Fixes: 314de7af06 ("anv: Initial support for VP9 decoding")
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38437>
Coverity notices we're reading off the end of the array here, which is
true. We also intend to do that because we want to read the next field as
well. Cast to a `void *` to help Coverity out.
CID: 1649593
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38437>
Use the syntactic sugar for heap operations on the vertex/tiler queue.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Suggested-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38826>
The spec requires FINISH_FRAGMENT calls to be issue in the exact same
order FINISH_TILING calls were, otherwise heap chunks that are still
used by in-flight IDVS/FRAGMENT jobs might be returned to the heap
leading to a UAF situation.
In order to guarantee FINISH_FRAGMENT ordering, we request the new
iterator scoreboard (the one to be used on the next RUN_FRAGMENT)
just before issuing our FINISH_FRAGMENT, and we select this next
iterator scoreboard as our signal scoreboard. This guarantees that the
next FINISH_FRAGMENT won't trigger until both the next RUN_FRAGMENT and
the current FINISH_FRAGMENT are done.
This new approach forces us to revisit the sequencing of our
issue_fragment() logic. Previously we were requesting a new scoreboard
before RUN_FRAGMENT, but now we're assuming the scoreboard has already
been claimed, either by the subqueue init logic (simple static assignment,
since all scoreboards are free at this time) or by the previous
issue_fragment() call.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38826>
Right now all we do is get the next available scoreboard, and set
it as the current iterator scoreboard, but the fragment queue is
about require something more involved to fix FINISH_FRAGMENT ordering
issue.
Provide a cs_iter_sb_update() block where everything between the
selection of a new scoreboard and the transition to this new
scorevoard is customizable. Implement cs_next_iter_sb() as a dummy
wrapper around this new construct.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38826>
We are about to add sequences where we will do
wait(cur_iter_sb),signal(next_iter_sb)
in some deferred operations. When that happens, the wait mask can't have
the signal sb set, otherwise the behavior is undefined.
On v11+, we have enough scoreboards to disallow the currently bound
endpoint SB from being returned on a NEXT_SB_ENTRY, so let's do that all
the time.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38826>
Knowing which defer mode is used is quite useful.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38826>
The name is misleading since it's only setting the endpoint scoreboard
on v11+. On v10, we shouldn't assume the "other" SB is always zero,
since we're passed the SB slot to use at init time (ls_sb_slot).
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38826>
Source assignment is mixed up in some of them. While at it, make
source argument names consistent with the descriptor field names.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38826>
Fix cs_extract_tuple() and implement cs_extract{32,64}() as wrappers
around cs_extract_tuple().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38826>
Unity's Vulkan backend used by Spilled! requires the vk_dont_care_as_load
workaround to achieve correct rendering. Observed on Turnip, in GMEM mode.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38863>
Since Metal doesn't pass clip distance into the fragment shader, we have to
do it ourselves. The CLIP_DIST0/1 varying slots are used to represent the
user-defined varyings we use to pass them from vertex to fragment and
a new intrinsic is added to represent the write to the built-in
clip_distance variable. Since the CLIP_DIST0/1 varying slots are not affected
by opt_varyings, there can be potential interface mismatches so the machinery
in msl_iomap.c is refactored to allow them to be output as a series of scalars
rather than vectors.
Reviewed-by: Aitor Camacho <aitor@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38839>
Add support for A840 and X2-85. Despite slice count, differences in
memory bus and clks, they are architecturally similar from the PoV of
the UMD.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38450>
Enable gen8 support. Sysmem, gmem, and binning work. DEQP gles2/3/31
tests are passing.
LRZ is not supported yet, and will follow later.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38450>
