Refactor the scale factors to highlight the 16-tile width requirement on
Tile4. The fast-clear simulator code associated with HSD 1407682962
also contains a 16-tile requirement for Tile4 surfaces (for the pitch).
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33776>
According to HSD 1407682962 and the associated simulator code,
fast-clear performance can be affected by: image alignment, tiling,
dimensionality, and row pitch. Redescribe surfaces in order avoid
fast-clearing at a slower rate.
Also, benchmarking the main patch in the performance CI (hw=A750)
shows that some traces are helped significantly:
* TotalWarWarhammer3 +5.58% (n=2)
* Factorio +3.75% (n=1)
* TerminatorResistance +3.3% (n=2)
* Borderlands3 +3.23% (n=2)
We could additionally increase the alignment requirements of surfaces in
order to deterministically increase fast-clear performance. That's left
out of this patch in order to avoid any functional pitfalls that can
arise with increased memory consumption. As a result, performance will
continue to be affected by how ISL/drivers/apps configure main surface
memory alignments (directly or indirectly).
Thanks to Lionel Landwerlin for pointing me to the relevant simulator
code.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11168
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11418
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33776>
Unify code which creates surfaces from buffers. The behavior is slightly
changed to use array layers to enable arrayed buffer clears (as needed).
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33776>
The assertion `assert(afence->seq_no <= *user_fence_cpu)` in
`amdgpu_fence_wait` can trigger a Mesa exit during GPU mode2 resets in
virtualized guest environments.
A GPU reset can cause the hardware to discard commands, including the
one that updates the user fence BO (`*user_fence_cpu`). This leaves
`*user_fence_cpu` with an older value, while `afence->seq_no` (from
command submission) is newer, leading to
`afence->seq_no > *user_fence_cpu` and triggering the assert.
Removing this assert prevents Mesa from exiting in this reset scenario.
No adverse side effects observed during testing. The assert appears
overly strict for hardware reset events where command completion is not
guaranteed.
Signed-off-by: Wei Zhao <wei.zhao@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34924>
It's only needed for old UVD without session context. Also remove
the NULL check for session context buffer as we always have the buffer.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34807>
The hardware requires a power of two bpe. To do that, the driver
needs to adjust the pitch/offset/extent based on a texel scale factor
which only applies to 96-bits formats.
This fixes new VKCTS coverage.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34927>
With EARLY_Z depth is written before FS is executed, so if FS writes
gl_SampleMask - the d/s written before FS would be incorrect since
sample mask can kill samples. However, if there is no d/s write
it's ok to kill fragment before FS.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34900>
Switch to using the newly available ir3_legalize_state API in
ir3_postsched. This has a few advantages:
- Prevents duplication of delay/sync logic. ir3_postsched is currently
missing a lot of the complexities implemented in ir3_legalize. Reusing
the logic makes sure ir3_postsched is kept up to date with these
complexities.
- Allows ir3_postsched to have a global view (i.e., across blocks) on
delay and sync state. Currently, all information is cleared at the
start of blocks which makes us underestimate required delays.
- Allows ir3_postsched to have a more accurate view on required sync
flags. We currently calculate requirement once based on whether an
instruction's sources come from a ss/sy-producer. This does not take
into account whether sources have already been synced. Now we can do
this.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34108>
sync_update currently only deals with the current instruction but there
are a few cases where syncs depend on the previous instruction (e.g.,
barriers). Add those to sync_update/ir3_required_sync_flags to have all
the sync logic centralized.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34108>
Now that we have the block's final cycle value available in its state,
we don't have to subtract it at the end of a block anymore, but we can
do it at the beginning when merging it into its successor state. This
will save us one iteration over all its ready slots.
Signed-off-by: Job Noorman <job@noorman.info>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34108>
Having the cycle as part of the state will become convenient for two
reasons:
- It will allow us to merge the state of predecessors without having to
normalize states at the end of blocks (i.e., we now have to subtract
the block's final cycle value from its ready slots at the end of the
block; having its final cycle value available in its state will allow
us to do this when merging predecessor states at the start of the
block).
- We can update the cycle value as part of delay/sync state update
routines. This way, the user doesn't have to worry about which
instructions should actually update the cycle as this logic is nicely
encapsulated.
This is part of the preparation for making the delay/sync legalization
logic available outside of ir3_legalize.
Signed-off-by: Job Noorman <job@noorman.info>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34108>
Resetting the ss/sy delays at the start of blocks would underestimate
the actual delays at runtime. Make the estimate more accurate by keeping
track of outstanding delays at the end of blocks and setting the initial
delays of blocks to the maximum of their predecessor blocks.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34108>
