Update vcn 1 encode interface, upgrade interface minor version from 2 to 9,
and add necessary parameters accordingly.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13511>
We've noticed issues with these tests when uprevving Mesa in Chrome OS.
This CI catches some existing failures, and some debug-build assertion
failures as well.
To do this, uprev deqp-runner for its new gtest-runner command. This
runner is not as efficient as I would hope, due to some expensive code in
gtest. I've reported the issue to gtest and it should be easily fixable,
but for now it at least means we get to use the same baseline/skip/flake
handling we have from deqp and piglit runners.
I also fixed build-libdrm for our rootfses to not throw away libdrm's
share directory, which was causing a bunch of test-time spam from radeon's
libdrm when trying to look up its marketing name tables (not that big of a
deal for deqp-runner, but really noisy for piglit and libva-utils which
make gallium screens approximatly per-test).
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13419>
This fixes flakes in dEQP-VK.pipeline.stencil.nocolor.format.* when run
after ycbcr tests. Apparently LRZ needs to know if there's a media
format enabled even if there are no color attachments, so we need to
write something here. Presumably any "normal" format would work but 0
seems like a good neutral choice.
Fixes: 9c895e13 ("tu: Emit GRAS_LRZ_MRT_BUF_INFO_0")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13578>
This is a new blitter command introduced on Tigerlake and expanded
substantially on XeHP. XY_BLOCK_COPY_BLT is actually fast, unlike
the legacy blitter commands. iris will use this in the future, and
anv hopefully could use it for a transfer queue someday as well.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13520>
We're going to want to use the blitter again on newer hardware,
which means we need to be able to use genxml to emit those commands.
Acked-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13520>
This asserts that the value supplied is non-zero. Useful for things
like MOCS fields on modern platforms where we really want to avoid
setting it to 0 (uncached).
mbz types cannot be flagged as nonzero.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We don't use bindless surface or sampler states today, and are unlikely
to ever implement that in i965, but we can set a MOCS value regardless
to avoid asserts in upcoming patches that assert MOCS isn't zero.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
This largely copies crocus's code for this (but with Gfx9+ handling).
This version also fixes missing MOCS settings on several platforms,
which we hadn't noticed were missing.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is disabled stream output targets, MOCS shouldn't matter, as
there's no actual buffer to be cached.
That said, it should be harmless to set MOCS for these null stream
output buffers; we can just assume a MOCS for generic internal buffers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We set MOCS on Ivybridge/Baytrail, but not Haswell, and not Skylake
and later. We shoud set it everywhere. While we're at it, we also
set it for null constant buffers, so that we aren't programming a 0
MOCS, to allow us to add some safeguards against that.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero. When we have entirely NULL surfaces, we just
default to the MOCS value for an internal buffer.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
The ISL MOCS infrastructure didn't exist when we wrote the i965 code,
but now that it does, we ought to use it, deleting a complicated mess
that was replicated all throughout the codebase.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero. When we have entirely NULL surfaces, we just
default to the MOCS value for an internal buffer.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is disabled stream output targets, MOCS shouldn't matter, as
there's no actual buffer to be cached.
That said, it should be harmless to set MOCS for these null stream
output buffers; we can just assume a MOCS for generic internal buffers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
This reorganizes the code so that we set fields in a tidy order:
1. Set the base addresses
2. Set either buffer sizes (Gfx8) or upper bound values (Gfx4-7)
(These are logically the same thing, but expressed differently.)
3. Set MOCS (Gfx6+)
I find this easier to follow.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We were only setting MOCS for dynamic state, surface state, instruction,
and indirect base addresses on Gen8+. We should set them on Gen6+.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is disabled stream output targets, MOCS shouldn't matter, as
there's no actual buffer to be cached.
That said, it should be harmless to set MOCS for these null stream
output buffers; we can just assume a MOCS for generic internal buffers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is 3DSTATE_VERTEX_BUFFERS where we set NullVertexBuffer.
It shouldn't matter here, as there's no actual buffer to be cached.
That said, it should be harmless to set MOCS for null vertex buffers.
We can assume an internal buffer and request isl's vertex buffer MOCS.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
This avoids MOCS != 0 assertions in later patches. iris also does this,
and we do it for the 3DSTATE_CONSTANT_ALL packet path as well. It's a
bit pointless, but it should hopefully be harmless also.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We were only setting this on Gfx9+. It's MBZ on Gfx8, but it exists
on Gfx7.x and doesn't have those restrictions there; we should set it.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero. When we have entirely NULL surfaces, we just
default to isl's MOCS value for an internal depth buffer.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is disabled stream output targets, MOCS shouldn't matter, as
there's no actual buffer to be cached.
That said, it should be harmless to set MOCS for these null stream
output buffers; we can just assume a MOCS for generic internal buffers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is 3DSTATE_VERTEX_BUFFERS where we set NullVertexBuffer.
It shouldn't matter here, as there's no actual buffer to be cached.
That said, it should be harmless to set MOCS for null vertex buffers.
We can assume an internal buffer and request isl's vertex buffer MOCS.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we missed
setting a non-zero MOCS was in 3DSTATE_CONSTANT_ALL packets which fully
disable all constant buffers. (If any constant buffer was present, we
would set an actual MOCS value.)
MOCS really shouldn't matter here, as there are no actual constant
buffers to be cached. That said, it should be harmless to do so, and
we can just assume a generic MOCS for internal buffers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We were leaving this blank due to a Broadwell restriction, causing our
constant buffers to be uncached. We later fixed this for Gfx12+, but
left Gfx9-11 without a fix. We should specify one.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero. When we have entirely NULL surfaces, we just
default to isl's MOCS value for an internal depth buffer.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We don't use bindless sampler states today, but when we do, we'll want
them to have proper MOCS values. This also avoids asserts in upcoming
patches which enforce that MOCS isn't zero.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is disabled constant buffers, where MOCS shouldn't matter, as
there's no actual buffer to be cached.
That said, it should be harmless to set MOCS for these null constant
buffers; we can just assume a generic MOCS for internal buffers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
isl now uses info->mocs regardless of whether there's any actual
depth/stencil/HiZ buffers involved, so pass it a legitimate one,
rather than zero. We just assume a generic internal MOCS when we
have entirely NULL surfaces.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is SURFTYPE_NULL surfaces, where MOCS really shouldn't matter,
as there's no actual surface to be cached.
That said, it should be harmless to set MOCS for these null surfaces;
we can just assume a generic MOCS for internal buffers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is SURFTYPE_NULL depth, stencil, and HiZ buffers, where MOCS
really shouldn't matter, as there's no actual surface to be cached.
That said, it should be harmless to set MOCS for these null surfaces.
We now set the one provided in info->mocs regardless of whether any
buffers actually exist or not.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We'd like to add safeguards against accidental use of MOCS 0 (uncached),
which can have large performance implications. One case where we use
MOCS of 0 is SURFTYPE_NULL surfaces, where MOCS really shouldn't matter,
as there's no actual surface to be cached.
That said, it should be harmless to set MOCS for these null surfaces;
we can just assume a generic MOCS for internal buffers.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
The Broadwell PRM says: "Constant Buffer Object Control State must
always be programmed to zero."
This patch changes the MOCS field in gen8.xml to be "mbz" type, so that
it's impossible to set it to a non-zero value.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
There are some fields which Must Be Zero, and we don't want to allow
setting them from the template struct, but we do want them in the XML
to allow them to be decoded properly, and for documentation purposes.
This adds a new "mbz" type, much like "mbo", except it doesn't set
anything in the struct. We also update the decoder to handle it.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
We had this field mislabeled as "Instruction Access Upper Bound", but
instruction state base address doesn't exist until Gfx5. This is
supposed to be the upper bound for indirect object base address,
matching the G45 copy.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13480>
Boyuan Zhang
Emma Anholt
Connor Abbott
Kenneth Graunke
Pierre-Eric Pelloux-Prayer