The previous patch changed the gfx12 CCS initial aux state from
pass-through to compressed-no-clear. This isn't always accurate.
This patch determines if a CCS is in the pass-through state by
inspecting the associated resources' bo field. In order to do that
clearly, move aux-state initialization out of
iris_resource_configure_aux (which can be called before BO creation).
Split up that logic and move the pieces into iris_resource_from_handle,
iris_resource_init_aux_buf, and a new function in ISL.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27835>
The extra_aux memory range holds the CCS portion of surfaces using
MCS_CCS or HiZ+CCS on integrated gfx12.x. Avoid memsetting because:
* There's no known CCS initialization requirement for MCS_CCS.
* ACM has the same documented initialization requirements for HIZ+CCS on
TGL/MTL, but iris doesn't initialize the CCS portion on discrete. For
TGL+, anv does not initialize the CCS portion of HiZ+CCS. Let's be
consistent with these other cases and avoid initialization.
If we end up needing to initialize the CCS, we can try come up with
something that will work for both integrated and discrete gfx12.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27835>
Previously, if first draw call with wasn't indexed but pipeline
had primitive restart enabled - primitive restart would be disabled
for draw calls, even indexed, that follow.
However, prim restart index works in non-indexed draw calls, but since
we don't emit fresh PC_RESTART_INDEX for them - they may use stale
value if prim restart is enabled for non-indexed draw calls.
So we have track the switch between indexed and non-indexed draw calls
and emit PC_PRIMITIVE_CNTL_0 for them.
Fixes car rear window in Need for Speed: Most Wanted (2012)
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27821>
this is a bandaid fix that allows users (zink) to actually call the
functions intended to be called. the real fix would be to figure out
which extensions are enabled on the device and then only GPA the
functions associated with those extensions
that's too hard though so I'm slapping some flex tape on it
cc: mesa-stable
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27834>
Lowering/layout is pretty much the same as direct descriptors. The
caveats is that since the descriptor buffers are not visible from the
binding tables we can't promote anything to the binding table (except
push descriptors).
The reason for this is that there is nothing that prevents an
application to use both types of descriptors and because descriptor
buffers have visible address + capture replay, we can't merge the 2
types in the same virtual address space location (limited to 4Gb max,
limited 2Gb with binding tables).
If we had the guarantee that both are not going to be used at the same
time, we could consider a 2Gb VA for descriptor buffers.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22151>
Those samplers live in the dynamic state base address and their offset
can be directly baking into the shaders.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22151>
We can address samplers from 3 different locations :
- binding table
- dynamic state base address
- bindless sampler base address (only Gfx11+)
Here we allow samplers to be address from the dynamic state base
address with the embedded sampler flag.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22151>
The way we implement embedded samplers will be to have the sampler
handle as a relocated constant in the shader.
This implies that 2 identical shaders with different embedded sampler
parameters must have different hash as we cannot reuse the final
shader binary.
So add the sampler hash to the descriptor set layout hash when the set
has embedded samplers.
This has the effect of creating multiple shader entries in the cache
unfortunately. An improvement over this would be to have a anv_device
map of (embedded samplers hash + shader hash) to shader in instruction
heap, so that pipeline caches only have a single entry regardless of
embedded sampler parameters.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22151>
Because we have 2 dynamic state heaps, we need to duplicate values.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22151>
We're about to use 2 different location for the dynamic state heap.
Which means at least on i915 we need 2 copies of all the fixed
(CPS_STATE, border colors, slice hash) stuff on the dynamic state
heap.
Let's avoid having the aux-tt tables in there too.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22151>
A number of allocations during command buffer building are sourced
from the dynamic state heap. They're not actually access using an
offset in the dynamic state heap, it just happens to be a conveninent
place.
Use different helpers for thoses so we dynamically change the dynamic
state heap location in the next commits.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22151>
We'll use a new heap & a new pool for descriptor buffers. The heap
will hold descriptor buffers, while the pool will only be used on
Gfx12.5+ for push descriptors.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22151>
vkd3d-proton uses a descriptor set with a single descriptor, so we
don't even need to copy the old data where there is an update.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22151>
In the fast-link case, we should just use the library shader and assume
that it's correct. We have to do this because we may not have a
precompiled shader in this case so we can't even generate the shader
hash.
In the link optimization case, we could still have a library shader
coming in from some library pipeline. That shader may happen to be
correct, in which case we can just use it and not even bother digging
around in the cache. In the more likely case, the keys won't match and
we should throw it away before we look up a different shader in the
cache and leak our reference.
Fixes: 9308e8d90d ("vulkan: Add generic graphics and compute VkPipeline implementation")
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27860>
KMD needs to be able to read and write the clear-color from CPU.
i915 can workaround it but Xe KMD will reject page flips with
clear-color bos that can be read from CPU.
So here it make sure that bos with the clear color information
are placed in a lmem portion that is CPU-visible, that is important in
PCIe small bar systems.
And as CCS in discrete GPUs are only supported in lmem this bo can't
become a IRIS_HEAP_DEVICE_LOCAL_PREFERRED(lmem + smem).
So here the IRIS_HEAP_DEVICE_LOCAL_CPU_VISIBLE_SMALL_BAR heap is selected.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26700>
This is intented to be used in cases where BOs can only be placed in
lmem but needs to accesible from CPU side.
Actual usage will be added in the next patch, here just adding the
heap type and all the handling.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26700>
