This commit moves boilerplate code surrounding NIR flags in a common
NAK_AS_U32 macro. The code only checks that the flag structure
has only 32 bits and then copies it into a 32-bit int.
Signed-off-by: Lorenzo Rossi <snowycoder@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34940>
Evergreen and cayman have the hardware support for this extension.
This is described by the manual as EXPORT_RAT_INST_INC_UINT_RTN
and EXPORT_RAT_INST_DEC_UINT_RTN.
This change was tested and passes the piglit tests (17/17)
on cypress, palm and cayman.
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34501>
'X4.exe' is the executable. But there is also a script 'X4' that is used to
launch the game. This script is what steam uses.
This updates driconf to match that.
This also brings the executable in line with other configs for the game.
Fixes: 5532f13566 ("driconf: override vendor id for X4 Foundations on NVK")
Fixes: 8654a7727f ("driconf: set vk_zero_vram driconf for X4 Foundations")
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34168>
This optimization used to optimize the allocated space for descriptors
when immutable samplers are equal. Though, this was basically broken :
- descriptor copies were broken for combiner image sampler (or sampler)
with equal immutable samplers because 96 bytes were copied instead of
64 bytes (cf. the linked ticket). This could be fixed but it's not
worth it.
- the value returned by vkGetDescriptorLayoutSupport() was broken, it
should have been 96 with no immutable samplers (or when they aren't
equal)
This optimization was also not applied for descriptor buffers which is
the default for vkd3d-proton and Zink. DXVK doesn't use db but it
doesn't use immutable samplers, so basically only native vulkan games
would be concerned.
Note that immutable samplers would still be inlined in shaders if no
indirect access which should be 99.9% of the usecase.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11165
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34928>
In a scenario where the viewports/scissors are a dynamic state but the
count is static (ie. updated when a graphics pipeline is bound), the
driver wasn't considering that and it was re-emitting the previous
number of viewports/scissors.
This fixes rendering issue with Blender.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13127
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34921>
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>
