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>
Fix defect reported by Coverity Scan.
Logically dead code (DEADCODE)
dead_error_line: Execution cannot reach this statement: return;.
Fixes: bdf93f4e3b ("v3dv/cmd_buffer: return early for draw commands if there is nothing to draw")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9890>
Section 8.9.4 (Compatibility Profile Texture Functions) of the
GLSL 4.20 spec outlines a number of builtin texture functions that
have been moved to compatibility shaders.
This change enforces those restrictions. Note we don't worry about
enforcing restrictions on the EXT_gpu_shader4 extensions of these
functions because EXT_gpu_shader4 should only be enabled for compat
already.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9887>
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>
It's flaky in producing Missing results. I've got an uprev that should
avoid the issue (and possibly a followon actual fix), but it's blocked on
being able to rebuild the arm containers.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9932>
This will allow us to reduce the number of situations where the
compiler workaround is needed on GFX10.3.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9924>
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 breaks up the monolithic draw path used for all draw calls into
pre/post functions to handle general setup and a couple helper functions
to more directly handle different draw modes in a way that's both more readable
and, potentially, more optimizable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8788>
Automatically include it if we're building with a driver that depends on
it, and don't include it if we're not. Avoids a footgun (building
something like panfrost without kmsro) with minimal effect on code size
in the "kmsro possible but not used" case. (This case primarily affects
Freedreno, but the Freedreno maintainers suggested this, so I think it's
ok.)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Suggested-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8893>
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>
Zink does not require VK_KHR_get_physical_device_properties2; we have
fallback-code in place for when that is lacking.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9925>
VkPhysicalDeviceFeatures::depthClamp isn't required until GL 3.2, where
we already list it. Remove the extra entry to avoid confusion.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9925>
