GitLab

That way we can actually import surfaces with modifiers & metadata
planes.

Tested with patches for ffmpeg to use this with kmsgrab & modifiers.

For AMD & multiplanar formats we always have 1 format plane = 1
memory plane, even with modifiers.

Intel (non Gallium) does have 1 format plane is 2 memory planes
for some modifiers with NV12. Currently with Gallium we don't really
have info about layer/plane ordering so this manually orders things
so that they align with Intel.

This shouldn't impact other drivers as without modifiers with metadata
planes this should give equivalent behavior to the old import path.
Reviewed-and-Tested-by: Leo Liu <leo.liu@amd.com>
Part-of: <!10815>

Extra memory planes don't need a sampler.
Reviewed-and-Tested-by: Leo Liu <leo.liu@amd.com>
Part-of: <!10815>

Otherwise we would always decompress when transitioning to the
foreign queue.

Fixes: 8b9033ad

 ("radv: Support DCC modifiers fully.")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <!10802>

Most stuff that depends on the value wouldn't be triggered anyway but
...

Fixes: b5ecf074

 ("radv: Ensure we never decompress or FCE read-only textures.")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <!10802>

We depend on the queue mask for some decisions ...

CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <!10802>

Instead of avoiding out-of-bounds access, avoid creating a load larger
than the original attribute. This should work just as well, since the only
situations expending a load helped was because we shrunk it first.

Also fixes a bug where a 3 component load (4 components with the first
component skipped) would be incorrectly expanded to 4 components because
the stride check would never be performed. Maybe we should avoid skipping
the first component in some situations, but I'm not sure if it's worth
the VGPR cost.

fossil-db (vega10):
Totals from 583 (0.39% of 149974) affected shaders:
CodeSize: 1496848 -> 1500868 (+0.27%); split: -0.03%, +0.30%
Instrs: 286155 -> 286575 (+0.15%); split: -0.07%, +0.22%
Latency: 2947101 -> 2946865 (-0.01%); split: -0.23%, +0.22%
InvThroughput: 797396 -> 797127 (-0.03%); split: -0.08%, +0.04%

fossil-db (polaris10):
Totals from 583 (0.39% of 151365) affected shaders:
SGPRs: 38880 -> 39216 (+0.86%)
VGPRs: 24440 -> 24356 (-0.34%)
CodeSize: 1506808 -> 1510876 (+0.27%); split: -0.01%, +0.28%
Instrs: 288735 -> 289167 (+0.15%); split: -0.06%, +0.21%
Latency: 2963263 -> 2961884 (-0.05%); split: -0.24%, +0.19%
InvThroughput: 802351 -> 801665 (-0.09%); split: -0.12%, +0.04%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <!9007>

Instead of assuming scalar alignment for an attribute, we can use the
required alignment of other attributes in a binding to expect a higher
one.

This uses the alignment of all attributes in the pipeline, not just the
ones loaded. This can create slightly better code, but could break
pipelines which relied on unused (and unaligned) attributes no being
loaded. I don't think such pipelines are allowed by the spec.

fossil-db (Sienna Cichlid):
Totals from 44350 (30.32% of 146267) affected shaders:
VGPRs: 1694464 -> 1700616 (+0.36%); split: -0.08%, +0.44%
CodeSize: 60207184 -> 58093836 (-3.51%); split: -3.51%, +0.00%
MaxWaves: 1175998 -> 1174948 (-0.09%); split: +0.02%, -0.11%
Instrs: 11763444 -> 11458952 (-2.59%); split: -2.60%, +0.01%
Latency: 70679612 -> 67062215 (-5.12%); split: -5.27%, +0.15%
InvThroughput: 11482495 -> 11362911 (-1.04%); split: -1.20%, +0.16%
VClause: 359459 -> 343248 (-4.51%); split: -6.36%, +1.85%
SClause: 422404 -> 419229 (-0.75%); split: -1.17%, +0.42%
Copies: 754384 -> 764368 (+1.32%); split: -1.74%, +3.06%
Branches: 197472 -> 197474 (+0.00%); split: -0.03%, +0.03%
PreVGPRs: 1215348 -> 1215503 (+0.01%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <!9007>

This reverts commit 209c8297

.

They are stable now.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <!11355>

Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <!11316>

Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <!11099>

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Emma Anholt <emma@anholt.net>
Part-of: <!11146>

This is a gallium driver for the Intel gfx 4-7 GPUs.

It was initially cloned from the iris driver by Ilia Mirkin,
then I ported over large reams of code from i965 until it worked.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <!11146>

965 and the mesa st disagree on how vertex elements are ordered when
edgeflags are involved. 965 wants them in gl_vert_attrib order,
but gallium supplies the edgeflag as the last vertex element regardless.

This adds a flag which is enabled for gen4/5 to denote that the
edgeflag is at the end. When we reap 965 later we can resolve this
better.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <!11146>

This gets hashed a lot, this reduces the size of this, and the other
keys by a small amount
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <!11146>

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <!11146>

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <!11146>

Sampler/image/surface views with different component sizes also need to
force demotion to uncompressed, as the UBWC metadata is not compatible.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <mesa/mesa!11343>

Similar to sampler views and shader images, if we get a surface view
with a non-UBWC compatible format while the underlying resource is UBWC,
we need to demote to uncompressed.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <mesa/mesa!11343>

The .NORM bit doesn't seem to do what we think or want.. tu also doesn't
set it, and things seem to work out better when we don't.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <mesa/mesa!11343>

Next patches fixes a bunch.. it will be easier to not update the xfails
by hand.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <mesa/mesa!11343>

Some vulkan functions are not loaded when the corresponding features are
not enabled, but the verifier checks for *all* functions, so make the
verifier more forgiving and use a stub to catch when we actually use a
function that is not loaded.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <mesa/mesa!11328>

Fix an obvious one-liner bug.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!11344>

There are size restrictions on 2D images which can't accommodate the
*full* 2D MSAA image. There's no way to make it work for 2D MSAA Array
images, but at least for the non-array variants, we can use the
no-mipmap variant which has a larger maximum size.

Fixes dEQP-GLES31.functional.shaders.builtin_functions.texture_size.*2d
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <!11285>

This is a hack.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!11253>

This is a hack.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!11253>

Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!11253>

Remove the ability to init/release repeatedly.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!11253>

To follow vn_renderer_{shmem,bo}_ops.
Signed-off-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <mesa/mesa!11253>

We use AML-Y since it's pretty fast and we have a bunch of boards running.
In exchange, to keep the farm from getting too busy, we disable
deqp-gles3/31 jobs by default, since the other gens get us pretty good
coverage.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <mesa/mesa!11193>

ensure this value is always updated
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <!10964>

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <!10964>

this is the value that needs to be set, not the actual rasterizer state

original function preserved to avoid driver changes
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <!10964>

this is necessary for handling index rewriting
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <!10964>

Now that there's a common NIR pass, there's no point in us doing this in
the back-end anymore.  In order to use this pass in i965, we do have to
make one tiny change.  Gallium runs the pass after assigning input and
output locations and so needs the pass to respect those locations and
num_inputs.  i965, however, runs it before any location assignment or
I/O lowering so we don't care.  We do, however, need the pass to succeed
with num_inputs == 0 because we set that later.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <!11313>

In theory you can rerun the info gather pass, but in practice that
doesn't always end well. Be consistent inside this pass and update the
info.

While we're here, change the inputs read to use VERT_BIT_EDGEFLAG.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <!11313>

With Yf and Ys tiling, everything is actually four dimensional because
we can have multiple depth or multisampled array slices in the same
tile.  This commit just enhances the calculations so they can handle it.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <!11330>

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <!11330>

We need to do this in order to handle Yf and Ys tiling because they use
a four-dimensional tile instead of laying everything out in two
dimensions.

v2 (Jason Ekstrand):
 - Update functions added since v1:
    - isl_surf_get_image_range_B_tile
    - blorp_can_hiz_clear_depth
    - get_image_offset_el

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> (v1)
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <!11330>

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <!11330>

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <!11330>