Values match how MinimumPointWidth, MaximumPointWidth is setup. This
fixes assert hit in debug build when packing the struct with too large
value for genxml.
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9942>
this includes:
* async buffer mapping/replacement
* async queue submission
* async (threaded) gallium flush handling
the main churn here is from handling async gallium flushes, which involves
creating multiple gallium fences (zink_tc_fence) for each zink fence (zink_fence).
a tc fence may begin waiting for completion at any time, even before the zink_fence
has had its cmdbuf(s) submitted, so handling this type of desync ends up needing
almost a complete rewrite of the existing queue architecture
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9935>
Need to bump up the size of texture target bitfield for MSVC.
Fixes: 0ce7c4a7c9 ("gallivm: Use the proper enum for the texture target bitfield.")
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9928>
lp_test_blend occasionally exceeds this on s390x, but we don't really
want to lose what little (hah) big-endian coverage we have.
Related: mesa/mesa#3437
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9921>
While barriers in Vulkan are scoped, we do not handle
nir_intrinsic_scoped_barrier, so we do not support them from NIR.
The reason why this hasn't been a problem seems to be that VTN is the
only place that respects them, so we haven't seen them yet.
But if the GLSL compiler starts respecting the setting, things will
start blowing up. There's WIP patches for this in !3339 already.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9949>
This one is a bit of a tough nut to deal with gracefully. Zink has a set
of base-requirements that we always require. There's no Gallium caps to
report these missing features, so we're essentially left with two options:
1. Fail to create the screen.
2. Ignore the missing fetures.
Solution 1 will lead to difficulties bringing up a new Vulkan driver on
Zink, and solution 2 will lead to mis-rendering.
Since Zink is mostly an opt-in driver to use when there's no OpenGL driver
available, we should probably do 2 for now. It seems better to have some
mis-rendering than no rendering at all.
But let's at least check, and print a warning. That way people get to
know what's up.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9925>
While we should probably use this extension at some point, we don't
currently do. So let's remove it, so the code documents the status-quo
instead of some potential future direction.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9925>
this massively speeds up memory access across the driver, specifically
for pbo-related operations
it does require that mapped memory is manually invalidated/flushed, however, and
we also need to manually align host-visible memory to be able to do that
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9884>
When more than 1 idr frames have been added to dpb list, there might be 2
frames with same poc in the dpb list. In this case, driver needs to search
the entire dpb list in order to get newly added reference frame with given poc
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9881>
Enabling this fast path, while making CPU side simpler
(and thus reducing driver's CPU overhead), forces us to
generate multiple VERTEX_BUFFER_STATE packets pointing to
the same buffer, but with slightly shifted BufferStartingAddress.
This is fine on GFX version >= 11 and < 8, but on version
8 and 9, thanks to internal details of the VF cache, vertex
data from each VERTEX_BUFFER_STATE is cached separately
and this results in a lot of cache misses.
Disabling this fast path restores previous performance levels.
On my SKL GT2 machine this improves performance in:
- GLB27 Egypt offscreen by 37%
- GLB27 TRex offscreen by 22%
- gfxbench5 Manhattan offscreen by 1.75%
- gfxbench5 Manhattan31 offscreen by 1.9%
- gfxbench5 Aztec Ruins high by 2.3%
In Intel performance CI on GFX version 9 it improves performance in:
- gfxbench5 Manhattan offscreen by 1.65%
- gfxbench5 Aztec Ruins normal offscreen by 1.33%
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3277
Fixes: 42842306d3 ("mesa,st/mesa: add a fast path for non-static VAOs")
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9857>
Fixes: 42842306d3 ("mesa,st/mesa: add a fast path for non-static VAOs")
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9857>
