Anv allows non-8x4-aligned depth buffer clears, but it has multisampled
HiZ disabled for BDW. iris allows multisampled HiZ on BDW, but disallows
non-8x4-aligned depth buffer clears.
Drop the unused optimization for non-8x4-aligned clears of multisampled
surfaces on BDW and use this opportunity to use some PRM text in the
code comment.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14091>
Binding table pool runs out of capacity quickly on modern games,
requiring new Surface Base Address instructions to be sent. That
is costly due to flushes and stalls. Increasing BT pool capacity
to 64KB improves performance several workloads.
Fallout4 +4%
Shadow of the Tomb Raider +4%
Borderlands3 +3%
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14483>
"most" times it isn't necessary to insert any pipeline barriers when binding
descriptors, as GL requires explicit barrier usage which comes through a different
codepath
the exception here is when the following scenario occurs:
* have buffer A
* buffer_subdata is called on A
* discard path is taken || A is not host-visible
* stream uploader is used for host write
* CmdCopyBuffer is used to copy the data back to A
buffer A now has a pending TRANSFER write that must complete before the buffer is
used in a shader, so synchronization is required any time TRANSFER usage is detected
in a bind
there's also going to be more exceptions going forward as more internal usage is added,
so just remove the whole fake-barrier mechanism since it'll become more problematic
going forward
Cc: 21.3 mesa-stable
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14496>
ensure that vertex key data is always zeroed when changing last stage since it will
be updated before draw anyway and can only cause problems if left alone here
fixes the following caselist:
dEQP-GLES31.functional.shaders.builtin_constants.tessellation_shader.max_tess_evaluation_texture_image_units
dEQP-GLES31.functional.tessellation_geometry_interaction.feedback.tessellation_output_quads_geometry_output_points
dEQP-GLES31.functional.ubo.random.all_per_block_buffers.25
cc: mesa-stable
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14482>
The idea is to offer the driver a way to execute on a different queue
than the one the app is using for Present.
For instance, this could be used to make the DRI_PRIME blit asynchronous,
by using a transfer queue.
So instead of creating a command buffer to be executed on present using
the supplied queue, this commit uses an internal transfer queue to perform
the blit.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13959>
Fixes a leak:
==47470== 60 bytes in 1 blocks are definitely lost in loss record 1,790 of 1,904
==47470== at 0x484186F: malloc (vg_replace_malloc.c:381)
==47470== by 0x58EBA6A: compile_vertex_list (vbo_save_api.c:535)
==47470== by 0x58EDABF: wrap_buffers (vbo_save_api.c:1021)
==47470== by 0x58EDF97: upgrade_vertex (vbo_save_api.c:1134)
==47470== by 0x58EE52F: fixup_vertex (vbo_save_api.c:1251)
==47470== by 0x58EFE9E: _save_Normal3f (vbo_attrib_tmp.h:315)
Fixes: 69615d92a0 ("vbo/dlist: realloc prims array instead of free/malloc")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14474>
Fixes a leak:
==46154== 48 bytes in 1 blocks are definitely lost in loss record 1,571 of 1,905
==46154== at 0x48466AF: realloc (vg_replace_malloc.c:1437)
==46154== by 0x5FC98EC: util_idalloc_resize (u_idalloc.c:43)
==46154== by 0x5FC9C16: util_idalloc_alloc_range (u_idalloc.c:125)
==46154== by 0x56FDB9F: _mesa_EndList (dlist.c:13681)
Fixes: b703d7c15f ("dlist: store all dlist in a continuous memory block")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14474>
The coarser 32x32 cross-slice hashing mode seems to lead to better L1
and L2 utilization due to the improved execution locality, however it
can also lead to a bottleneck in a single slice, especially in
workloads that concentrate heavy rendering in small areas of the
screen (e.g. SynMark2 OglGeomPoint, OglTerrain*) -- This effect is
mitigated here by performing a permutation of the pixel pipe hashing
tables that ensures that adjacent rows map to pixel pipes as far away
as possible in the caching hierarchy.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13569>
Unlike the Gen11 code, this requires us to allocate a pipe_resource
for the pixel pipe hashing tables and hold a reference to it from the
context, since we need to add it to the validation list of every
batch, the tables may be accessed by the hardware at any time after
they're specified via 3DSTATE_SLICE_TABLE_STATE_POINTERS.
Note that this has an effect even for unfused native die platforms,
since the pixel pipe hashing tables we intend to program aren't
equivalent to the hardware's defaults on such configs.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13569>
This starts off with the simplest possible pixel hashing table
calculation that just assigns consecutive indices (modulo N) to
adjacent entries of the table, along the lines of the existing
intel_compute_pixel_hash_table(). The same function will be improved
in a future commit with a more optimal calculation.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13569>
Samuel Pitoiset