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>
The GLSL spec says it's an error if a shader statically writes to these
2 variables.
Until this commit, Mesa refused to link a shader if it had an unused
function writing to one of these variables while another (used) function
wrote to the other.
This commit adds an option to perform dead function elimination after
the intra-stage linking step but before performing these checks.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12897>
It's undefined to not export a position but some applications rely
on that. The position is always initialized to 0,0,0,1 everywhere else
if not exported.
Fixes KHR-GL46.shader_image_load_store.multiple-uniforms with Zink.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13470>
Those appear not to be recognized anymore by perfetto.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Antonio Caggiano <antonio.caggiano@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13571>
1. advertise high hit rate cache combinations, and we should limit the
caches to those only require device memory pool alloc
2. use size = 1 to ask for buffer memory requirements so that we do a
sanity check on our assumption of returned size and alignment. For
implementations don't meet our assumption, continue without cache.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>
This change estimates the max_buffer_size with quick sort. Try to
avoid some traffic upon device creation time, but not worth adding a
buffer simple create api to avoid the extra requirement query traffic
since this is temporary.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13428>
this check was illegal because the usage bits weren't yet populated,
so add another check after usage bits are determined to figure out if
CUBE_COMPATIBLE can be applied
additionally, checking sample counts was never needed since the spec
prohibits CUBE_COMPATIBLE use with multisampling
zink DEBUG: ERR: 'Validation Error: [ VUID-vkGetPhysicalDeviceImageFormatProperties-usage-requiredbitmask ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x991b3105 | vkGetPhysicalDeviceImageFormatProperties: value of usage must not be 0. The Vulkan spec states: usage must not be 0 (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VUID-vkGetPhysicalDeviceImageFormatProperties-usage-requiredbitmask)'
Fixes: 71494c4874 ("zink: only mark resources as cube-compatible if supported")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12580>
Hear that it matters for RGP. This is the most likely scenario where
we would hit this workaround, given the tooling for profiling on the
deck will set profile_peak as workaround for hangs.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13534>
The test names are definitely unique (deqp has specific prefixes, piglit
uses '@' as a separator instead of '.'), so we can just have a single file
regardless of test type. Merges the two groups of xfails together so you
can't mix up which file to edit (I certainly have), and so that we don't
need to introduce yet another set of files when we add gtest for libva.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13517>
We have two testsuites with the same format for fails/flakes/skips files,
and test names that are definitely unique. As I'm about to add a third
testsuite (gtest for libva-utils), so let's have just one file each for
fails/flakes/skips instead of one per type of testsuite. This starts the
move with just the bulk rename of deqp.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13517>
While there seems to be no bug with the state things are today, I was
recently doing some debugging and put an iris_bo_wait() before a
bo_close() in iris_bufmgr_destroy(), which caused an issue since the
bo_deps_lock mutex had already been destroyed.
Since there are quite a few things we do with the bufmgr after
destroying the mutexes, I figured we should probably postpone mutex
destruction in order to be a little safer against future code
modifications like the one I just did.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13494>
While filling out surface state, pass correct aux usage for storage
images as we support compression on XeHPG.
v2: (Jason Ekstrand)
- Move assertion down a bit
- Use general layout aux usage
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3606>
this moves more code to nir passes, which makes it easier to debug
and also allows deleting some much-more-difficult-to-read ntv code
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13484>