Our linear alignment constraint for display is more restrictive than
render target. So make sure image in linear tiling created with
modifier support display constraints.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>

Whenever modifiers are used, assume that the surface might be using
for display.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>

The GBM API is missing a usage parameter for
gbm_bo_create_with_modifiers(). This is causing problems for
application that want to flip a buffer on KMS because our HW's
alignement constraints for display are more restrictive than for
render target. To address this issue, assume that if a modifier is
ever specified the display usage should be considered.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Closes: #1825

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

We're about to move this logic to ISL for 2 reasons :

   - We have slightly different implementation in anv, i965 & iris.
     All of them have the same goals and should produce the same
     result.

   - There are implications on requesting display usage with
     modifiers. In particular TILING_X is not supported by display on
     Gen8. So we need to drop that modifier there.

v2: Add Gen12 handling added by Nanley in 83fc15e5

 ("iris: Drop
    support for I915_FORMAT_MOD_Y_TILED_CCS on TGL+")
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

This is what the HW provides us.  If we need integer pixel centers, we
want the state tracker to do the lowering pass so that it gets to optimize
on the subtract.  This is also the shader instructions that the blob is
doing on GLES, and is what Vulkan wants too, as was noted in MR !4172.

shader-db on a630:
total instructions in shared programs: 186689 -> 186168 (-0.28%)
total nops in shared programs: 66253 -> 66139 (-0.17%)
total non-nops in shared programs: 120436 -> 120029 (-0.34%)
total dwords in shared programs: 292192 -> 291168 (-0.35%)
total last-baryf in shared programs: 4810 -> 4734 (-1.58%)
total full in shared programs: 10176 -> 10195 (0.19%)
total constlen in shared programs: 54589 -> 54575 (-0.03%)
total sstall in shared programs: 24582 -> 24802 (0.89%)
total (ss) in shared programs: 3921 -> 3925 (0.10%)
total (sy) in shared programs: 1934 -> 1923 (-0.57%)

Tested-by: Marge Bot <mesa/mesa!4223>
Part-of: <mesa/mesa!4223>

In trying a full build under AOSP, I ran into the following error:

In file included from external/mesa3d/src/gallium/drivers/r600/sfn/sfn_nir_lower_fs_out_to_vector.cpp:33:
external/libcxx/include/set:942:26: error: the specified comparator type does not provide a const call operator [-Werror,-Wuser-defined-warnings]
    static_assert(sizeof(__diagnose_non_const_comparator<_Key, _Compare>()), "");
                         ^
external/mesa3d/src/gallium/drivers/r600/sfn/sfn_nir_lower_fs_out_to_vector.cpp:78:34: note: in instantiation of template class 'std::__1::multiset<nir_intrinsic_ins
tr *, r600::nir_intrinsic_instr_less, std::__1::allocator<nir_intrinsic_instr *> >' requested here
   using InstrSubSet = std::pair<InstrSet::iterator, InstrSet::iterator>;
                                 ^
external/libcxx/include/__tree:967:5: note: from 'diagnose_if' attribute on '__diagnose_non_const_comparator<nir_intrinsic_instr *, r600::nir_intrinsic_instr_less>':
    _LIBCPP_DIAGNOSE_WARNING(!std::__invokable<_Compare const&, _Tp const&, _Tp const&>::value,
    ^                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
external/libcxx/include/__config:1244:21: note: expanded from macro '_LIBCPP_DIAGNOSE_WARNING'
     __attribute__((diagnose_if(__VA_ARGS__, "warning")))
                    ^           ~~~~~~~~~~~
1 error generated.

Which is pretty opaque to me, but searching the web suggested
adding a cost, which seems to resovle it.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Marge Bot <mesa/mesa!4175>
Part-of: <mesa/mesa!4175>

This is already defined in
  src/broadcom/cle/v3d_packet_helpers.h:42:9

And was causing build issues in AOSP when building with mmma
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Part-of: <mesa/mesa!4175>

Building with AOSP I'm seeing:

external/mesa3d/src/gallium/drivers/etnaviv/etnaviv_screen.c:245:31: error: signed shift result (0x100000000) requires 34 bits to represent, but 'int' only has 32 bits [-Werror,-Wshift-overflow]
         system_memory = 4096 << 20;

system_memory is a uint_64t, so this patch addresses the issue
by casting 4096 to a unint_64t before the shift is done.
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Part-of: <mesa/mesa!4175>

Change the MESA_ENABLE_LLVM checks in Android.mk
files in order to get mesa3d to build w/ AOSP
using mmma.

This tries to re-create a change that was introduced
in the following merge in the AOSP branch:
  69f2c0128d2b Merge branch 'aosp/upstream-18.0'
Acked-by: Tapani Pälli <tapani.palli@intel.com>
Acked-by: Mauro Rossi <issor.oruam@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Part-of: <mesa/mesa!4175>

Previously, we were initializing the CCS to 0xFF for MCS+CCS due to a
misunderstanding of the following lines in the bspec:

    The following are the general SW requirements for MCS buffer clear
    functionality:
        ...
         - If Software wants to enable Color Compression without Fast
           clear, Software needs to initialize MCS with zeros.
         - Lossless compression and CCS initialized to all F (using HW
           Fast Clear or SW direct Clear) on the same surface is not
           supported.

The first line does not refer to the CCS as the comment author supposed
but refers to the MCS as the comment says.  It means that if you want to
use MCS compression without a fast-clear, you should initialize the MCS
to 0x00.  This is because the value 0x00 in the MCS means "all data is
in plane 0" which is a perfectly valid non-fast-clear initialization.
It's also the value the MCS should be in if you do a RECTLIST slow-clear
where the primitive fully covers each pixel such that the same value is
written to all samples.

The second line in the above quote seems to imply that CCS fast-clear is
incompatible with MCS fast-clear.  In particular, MCS+CCS fast-clear
uses a 0xff value in the MCS (like on Gen7-11) and leaves the CCS in
either the compressed or the pass-through state.  Therefore, we should
initialize the CCS to 0x00 even for MCS+CCS surfaces.

Reviewed-by: Sagar Ghuge<sagar.ghuge@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Tested-by: Marge Bot <!4074>
Part-of: <!4074>

When the caller of the isl_surf_init() specifies a row pitch, do not
consider the minimum CCS requirement if it's incompatible with the
caller's value.

isl_surf_get_ccs_surf() will check that the main surface alignment
matches CCS expectations.

v2: Simplify checks (Nanley)

v3: Add Comment about isl_surf_get_ccs_surf() (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Fixes: a3f6db2c

 ("isl: drop CCS row pitch requirement for linear surfaces")
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Tested-by: Marge Bot <mesa/mesa!4243>
Part-of: <mesa/mesa!4243>

We could be creating a Y-tiled surface that isn't going to use CCS
(this could be the case when clearly indicated through modifiers).
Don't apply the main surface pitch alignment constraint in that case.

v2: Use logical NOT (Sagar)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: a3f6db2c

 ("isl: drop CCS row pitch requirement for linear surfaces")
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!4243>

Y tiling is supported for display on Gen9+ so don't filter it from the
possible flags.

v2: Drop Yf from display supported tilings on Gen12+ (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <!4243>

We're missing a requirement for alignment of row pitch for the display
HW. In linear tiling, the row pitch must be a 64bytes aligned.

v2: Use correct formula to align to 64bytes (Chad)

v3: Matching {} (Jason)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!4243>

Same as we do for a630 (docker) tests.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Tested-by: Marge Bot <mesa/mesa!4229>
Part-of: <mesa/mesa!4229>

It's time to start getting the calendar going for 20.1 so that everyone
is clear on when the close date for new features is. Eric Engstrom has
agreed to help out with the 20.1 series, and will be the primary point,
he's also helping out with a few of the 20.0.x point releases.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Tested-by: Marge Bot <mesa/mesa!4077>
Part-of: <mesa/mesa!4077>

pipeline-db (Navi, ACO):
Totals from affected shaders:
SGPRS: 11840 -> 11840 (0.00 %)
VGPRS: 19012 -> 19124 (0.59 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Scratch size: 3696 -> 3696 (0.00 %) dwords per thread
Code Size: 998680 -> 921388 (-7.74 %) bytes
LDS: 19646 -> 19646 (0.00 %) blocks
Max Waves: 3398 -> 3401 (0.09 %)

pipeline-db (Navi, LLVM):
Totals from affected shaders:
SGPRS: 17016 -> 17128 (0.66 %)
VGPRS: 19564 -> 14876 (-23.96 %)
Spilled SGPRs: 0 -> 0 (0.00 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Scratch size: 3872 -> 3872 (0.00 %) dwords per thread
Code Size: 820416 -> 743576 (-9.37 %) bytes
LDS: 0 -> 0 (0.00 %) blocks
Max Waves: 3367 -> 3534 (4.96 %)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-By: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Marge Bot <mesa/mesa!4193>
Part-of: <mesa/mesa!4193>

Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-By: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
CC: <mesa-stable@lists.freedesktop.org>
Part-of: <mesa/mesa!4193>

Currently, the worker threads are very aggresively
polling for new tasks. If the work is not constantly
fed into the pipeline (which is a case for most of
interactive applications), this creates unnecessary
memory pressure and is using CPU cycles that
could otherwise be used by the applications.
The change implements simple back off mechanism
to help with this problem

Change by Tomasz Pyra (tomasz.pyra@intel.com)
Reviewed-by: Alok Hota <alok.hota@intel.com>
Reviewed-by: Jan Zielinski <jan.zielinski@intel.com>
Tested-by: Marge Bot <mesa/mesa!4226>
Part-of: <mesa/mesa!4226>

Closes: mesa/mesa#2598

Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: Marge Bot <mesa/mesa!4214>
Part-of: <mesa/mesa!4214>

This fixes a GPU hang on radeonsi.

It only works if optimizations have already been run.

Cc: 19.3 20.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Marge Bot <mesa/mesa!4194>
Part-of: <mesa/mesa!4194>

MRT not yet supported to keep things easy.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Tested-by: Marge Bot <mesa/mesa!4242>
Part-of: <mesa/mesa!4242>

It ingests the output of ATEST, whatever that actually is.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

Only fp32 for now.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

ATEST actually takes two sources and has a destination. Although the
details are a little funny, we should still model this correctly.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

There's an easy mapping for this, so let's do it. Note we do this at
schedule-time instead of emit since we'll need to lookahead clause
types. The alternative is a prepass running after schedule but before
codegen, but there's no reason not to just stick it here when we're
preparing bi_clause in the first place.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

It makes bitwise property checking annoying.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

Also note that type=1 is for load_vary.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

We already track almost all the information we need, let's dump it onto
the wire now.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

They bypass the usual mechanism entirely, let's add some props to
describe this and respect them.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

Annoyingly long code to do so, but this should theoretically work for
both direct and indirect load_vary. Still need to handle destination.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

For direct, this is just 0, but for indirct, this is a sample mask
preloaded in R61. Handle this at code emit time instead of trying to do
crazy monkeypatching later.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

Allow it to work with ADD ops and stub out some immediate fetching
infrastructure (currently only works with 0).
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

Handling will be... somewhat tricky.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

Choo choo.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

This is our first instruction we've emitted, requiring us to pipe
through registes/ports and various details from the IR. It's quite a bit
of code, but overall I'm happy with this structure. With some tedium we
should be able to emit the rest of the ALU ops this way, too.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

So we can pack regular FMA ops.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>

We'll want to set these manually for schedule-time passthrough, as well
as use the enum for packing.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <mesa/mesa!4242>