some apps (most notably Wolfenstein: The New Order) have broken multi-context
buffer usage in which one context will attempt to write to a buffer while
another context holds unflushed usage, and the unflushed context will never
flush until the buffer write completes
it's impossible to handle this scenario correctly without deadlocking,
so add some handling to try waiting and then yolo the buffer write if
a deadlock would occur
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19141>
The flush_resources recorded in the context need to stay alive until
the context is flushed, at which point additional resolve operations
are done to those resources. While the backing BO is alive due to being
referenced in the cmdstream, the resource might already be destroyed
at this point.
Keep a reference to the resource to make sure it is still available at
context flush time.
Fixes: 7b9d8d1936 ("etnaviv: flush used render buffers on context flush when neccessary")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19280>
So far, only IMG drivers cannot handle out of bounds layer values.
Ideally, a vulkan extension will be drafted to detail this behavior.
But for now if KHR-GL46.texture_cube_map_array.color_depth_attachments
fails, then needs_sanitised_layer is probably needed.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19163>
GL spec forces driver to ignore gl_Layer, if layered rendering
is not enabled.
Since vulkan doesn't have the same bavior, emulate this by forcing
gl_Layer to 0, based on driver internal state.
This was seen as failure in
KHR-GL46.texture_cube_map_array.color_depth_attachments
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19163>
This state is needed to make sure gl_Layer values are set to 0,
when the framebuffer is not layered accorfing to GL spec.
Specifically Section 9.8 Layered Framebuffers of GL46 spec:
A layer number written by a geometry shader has no effect if
the framebuffer is not layered.
Vulkan has no carve out for this, so zink must handle this by
sanitising gl_Layer (next commit in the series).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19163>
Now that all gfx pipelines share the same push constant layout,
create a screen wide push const only layout that is compatible
with all future programs.
This layout will be used to update push constant values, so that
the update can happen at any point before draw call.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19163>
Extend vs_pushconst structure to all gfx stages and make sure,
the push constant memory layout is defined in one place and
is therefore always correct.
No functional change, but should make adding new members to
zink_*_push_constant easier.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19163>
On Q2RTX shaders :
Instructions in all programs: 31039 -> 26150 (-15.8%)
SENDs in all programs: 1587 -> 1148 (-27.7%)
Loops in all programs: 4 -> 4 (+0.0%)
Cycles in all programs: 420218 -> 392179 (-6.7%)
Spills in all programs: 157 -> 132 (-15.9%)
Fills in all programs: 337 -> 262 (-22.3%)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16556>
The intel backend compiler is not dealing with the scratch loads
emitted by this pass very well. There are 2 reasons for this :
- all loads are at the top of the shader
- the loads are global load intrinsics (cannot be differentiated
from ssbo loads for example)
This leads the backend to generate ridiculous amount of spills.
To help a bit (actually quite a lot), we can move the scratch loads in
the blocks where they're needed, using the dominance information.
Quite often that also ends up moving loads in a block that might not
be reached by all the lanes, so we're potentially avoiding some loads.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16556>
The previous pass shrinking values stored on the stack might have left
some gaps on the stack (a vec4 turned into a vec3 for instance).
This pass reorders variables on the stack, by component bit size and
by ssa value number. The component size is useful to pack smaller
values together. The ssa value number is also important because if we
have 2 calls spilling the same values, then we can avoid reemiting the
spillings if the values are stored in the same location.
v2: Remove unused sorting function (Konstantin)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16556>
For example, if we store to scratch a vec4 but only a subset of
components are used after the load operation.
v2: Use nir_intrinsic_write_mask (Konstantin)
Use u_foreach_bit() instead of u_bit_scan() (Konstantin)
Fix mask building loop (Konstantin)
v3: Fix reswizzle (Konstantin)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16556>
