Without this the cache setup was crashing with CL and the dynamic
pipe libraries.
Reported and debugged on irc by consolers
Cc: mesa-stable
Acked-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16341>
(cherry picked from commit 74976640b3)
without dynamic vertex input, pipeline vertex state must be recalculated
if buffer strides change or the enabled buffer mask changes in order
to accurately handle dynamic state stride VUs
cc: mesa-stable
fixes:
spec@!opengl 1.1@array-stride
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16563>
these might hit u_blitter later, which will require rt usage
to handle texture views, so add rt usage now to avoid failing later
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16563>
these caches ignore pNext from the create info since the pNext cannot
affect the eventual object that is created, so comparing it will break
the hash table
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16563>
this is one of those cases where some bizarro format is being created
for sampling only, but gallium blasts out all the bind flags at once
trust that we're not going to do anything too crazy and let surface
usage pruning handle the rest
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16563>
the idea here is that if a resource is intended to be used solely as a rendertarget
and can't be blitted to or drawn to, then resource creation should fail
but if the resource might be e.g., a texture, then it can probably hit the subdata
path and be fine
Fixes: 37ac8647fc ("zink: reject resource creation if format features don't match attachment")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16563>
this otherwise makes it impossible to accurately do hardware driver
fallback, as zink will create a sw context instead of failing, superceding
the actual sw driver priorities
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16572>
Without this change the values are always 0. This breaks
Maya which uses this value to create a pbuffer (and then
fails).
This commit is based on b91e1e38e8 which does the same
for EGL.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16496>
(cherry picked from commit 8779a5b84c)
this is slightly more nuanced: if this is ONLY a fragment state,
pDepthStencilState must exist, but if it's BOTH fragment and output,
then pDepthStencilState must only exist if zs attachment is used
Fixes: d4d5a7abba ("lavapipe: implement EXT_graphics_pipeline_library")
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16457>
(cherry picked from commit 5f83571f92)
depth and stencil states should only be set if the corresponding attachment
is present, otherwise they should be ignored. this is different from
ignoring the entire VkPipelineDepthStencilStateCreateInfo struct, as
it's possible that only depth or only stencil may be present
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16457>
(cherry picked from commit 0b2d383316)
the code here was fine for checking the base resource unbinds and whatever,
but it never actually destroyed the surfaces/bufferviews created,
which meant they were always being leaked
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16508>
(cherry picked from commit 1526df283c)
these have implicit refs from the surface/bufferview that gets created,
so adding a ref here is redundant and less performant
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16508>
(cherry picked from commit d0df488970)
Previously this check was skipped for pools with
VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT unset, but after
96a240e1 we need to check this otherwise we risk overflowing
radv_descriptor_pool::entries into the host memory base
This fixes a crash to desktop when launching Dota 2, which overallocates
descriptor sets and expects an error to allocate another descriptor pool
Fixes: 96a240e176 ("radv: fix memory leak of descriptor set layout")
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16490>
(cherry picked from commit 580046e49f)
this existed in order to reset query pools in advance so they
would never overflow. now the pools are reset every time the query
is started, so this behavior is no longer necessary
fixes#6475
Fixes: 57dd05616f ("zink/query: rewrite the query handling code to pass validation.")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16484>
(cherry picked from commit 1c62c6bafd)
We no longer emit STATE_BASE_ADDRESS in every batch on XeHP, so the
decoder might not know what the various base addresses are if it's only
looking at a single batch. Fortunately, they also never change, so we
can just emit them once here.
On earlier platforms, initializing them here should be harmless. We'll
emit STATE_BASE_ADDRESS if we change them, which will update these.
Thanks to Iván Briano for catching this.
Fixes: 8831cb38aa ("anv: Stop updating STATE_BASE_ADDRESS on XeHP")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16287>
(cherry picked from commit ad537edc7c)
Mostly Matt Roper's kernel patch commit message:
The IDs added here are the subset reserved for 'motherboard down'
designs of DG2. We have all the necessary support upstream to enable
these now.
The remaining DG2 IDs for add-in cards will be enabled in a future
patch once some additional required functionality has fully landed.
Ref: https://patchwork.freedesktop.org/patch/msgid/20220425211251.77154-3-matthew.d.roper@intel.com
Cc: 22.1 <mesa-stable>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16449>
(cherry picked from commit ad565f6b70)
add_src was ignored and i32_0 was always used.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Fixes: 1e49018ced ("amd: Add extra source to the mbcnt_amd NIR intrinsic.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16427>
(cherry picked from commit db2fd0ca83)
