The HW deals with overflow automatically, and presumably does it better
(only disabling for pipes that had overflow, and using the visiblity data
available before the overflow)
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5565>
Ensure main surfaces are properly 64KB-aligned (as suggested by Jordan)
and map the main surface addresses to aux surface addresses on import.
v2. Add a Bspec quote. (Sagar)
v3. Add a bit more to the Bspec comment. (Ken)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (v2)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5420>
Makes iris pass a subtest of the fcc-write-after-clear piglit test
(fast-clear tracking across layers 1 -> 0 -> 1) on gen12.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5363>
Add a new aux usage which more accurately describes the behavior of
CCS_E on gen12. On this platform, writes using the 3D engine are either
compressed or substituted with fast-cleared blocks.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5363>
For texturing and draw calls, HW expects the clear color to be in two
different color spaces after sRGB fast-clears - sRGB in the former and
linear in the latter. Up until now, iris has stored the clear color in
the sRGB color space. Limit the allowable clear colors for sRGB
fast-clears to 0/1 so that both color space requirements are satisfied.
Makes iris pass the sRGB -> sRGB subtest of the fcc-write-after-clear
piglit test on gen9+.
v2:
* Drop iris_context::blend_enables. (Ken)
* Drop some more resolve-related blend-state-tracking code.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4972>
For rendering operations, avoid adding or using fast-cleared blocks if
the render format is incompatible with the clear color interpretation.
Note that the clear color is currently interpreted through the
resource's surface format.
Makes iris pass subtests of the fcc-write-after-clear piglit test:
* UNORM -> SNORM, partial block on gen8+.
* linear -> sRGB, partial block on gen9+.
* UNORM -> SNORM, full block on gen12.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4972>
Remove the CCS_D fallback logic so that iris doesn't attempt to use a
non-existent surface state for some renders. Also, add an assertion to
catch the issue.
The fallback in iris_resource_render_aux_usage can lead to this problem
because it doesn't account for the fact that surface states created from
resources with the Y_TILED_CCS modifier may only have CCS_E or NONE as
aux usages (due to iris_resource_create_with_modifiers).
Without this change, the next commit would have triggered the fallback
and regressed the following tests on gen9:
* dEQP-EGL.functional.wide_color.window_888_colorspace_srgb
* dEQP-EGL.functional.wide_color.window_8888_colorspace_srgb
* dEQP-EGL.functional.wide_color.pbuffer_888_colorspace_srgb
* dEQP-EGL.functional.wide_color.pbuffer_8888_colorspace_srgb
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4972>
It seems a lot of the lowerings being run the second time were
unnecessary. In addition, when const_state is moved to the variant,
then it will become impossible to know ahead of time whether a variant
needs additional optimizing, which means that ir3_key_lowers_nir() needs
to go away. The new approach should have the same effect, since it skips
running lowerings that are unnecessary and then skips the opt loop if no
optimizations made progress, but it will work better when we move
ir3_nir_analyze_ubo_ranges() to be after variant creation.
The one maybe controversial thing I did is to make
nir_opt_algebraic_late() always happen during variant lowering. I wanted
to avoid code duplication, and it seems to me that we should push the
_late variants as far back as possible so that later opt_algebraic runs
don't miss out on optimization opportunities.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5508>
The only difference between this and `const_state->num_ubos` was that
the latter is counting # of ubos loaded via `ldg` (based on UBO addrs
in push-consts). But turns out there isn't really any reason to care.
Instead just add an early return in the one code-path that cares about
the number of `ldg` UBOs.
This gets rid of one more thing we need to move from `ir3_shader` to
`ir3_shader_variant`.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5508>
As with const_state, this will also need to move into the variant. To
simplify that, just move it into the const_state itself, since after all
it is related.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5508>
The `ubo_state` will also need to move to `ir3_shader_variant`. But we
can prepare for that and simplify things a bit if we calculate the
cmdstream on first emit, once we already have the appropriate variant.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5508>
We are going to want to move this back to the variant, and come up with
a different strategy for binning/nonbinning to share the same constant
layout, in order to implement shader-cache support. (Since then we
can have a mix of dynamically compiled variants and cache hits, so there
is no good place to serialize the const-state.)
To reduce the churn as we re-arrange things, move direct access to the
const-state to a helper fxn. This patch is the boring churny part.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5508>
I'm not sure whether this should actually be a barrier accross all
shader processing units, the TGSI code path seems to handle this
only by using GROUP_BARRIER, so let's do the same here.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5206>
And add quality params for this version
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Thong Thai <thong.thai@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5501>
Due to hardware change on VCN3
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Thong Thai <thong.thai@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5501>
This flag was never used by VCN previously, and now
it's used for feature that is not applied to us.
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: James Zhu <James.Zhu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5501>
Reduce linear alignment, and rework the layout code a bit.
This rework has a side effect of also increasing the alignment on linear
levels of tiled (non-ubwc) cpp=1 and cpp=2 layouts. Since we should be
UBWC for those cases anyway, its not a big loss.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5013>
"FETCHSIZE" is actually a "minimum pitch" or "pitchalign" value that's
relevant for mipmaps. The 0 value means 64-bytes. Understanding this allows
some simplifications and will make it possible to use less alignment on
linear formats.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5013>
All squashed into a single commit because it shouldn't have any
behaviour change, except that it might work now on platforms where it
was broken because F_DUPFD_CLOEXEC is not supported but FD_CLOEXEC is.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5369>
extensions need to have their feature structs passed in pNext to be enabled,
so switch to using the feature struct here in preparation for that
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5163>
this cap creates a different varying output which remains constant to be
emitted by xfb, allowing us to drop the special-casing code in ntv
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5163>
this adds:
* context hooks for gallium stream output methods
* handling for xfb-related queries
* barrier management for pausing and resuming xfb
loosely based on patches originally written by Dave Airlie <airlied@redhat.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5163>
