Speeds up compiling shaders/skia/781.shader_test in shader-db by 8x
(Icecream95).
...At least it did before I extended to support register allocation of vec8. On
Valhall, texture instructions require up to 8 consecutive registers. To handle
this, provide for vec8 register allocation. Liveness was already (accidentally?)
vec8. The increased memory requirement is acceptable given that the interference
matrix is now stored sparsely (Alyssa).
Icecream95 reports the vec8 changes hurt RA performance by about 1% on average.
I consider this acceptable for now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16780>
This is an array which can either be sparse or dense, and was designed
to be used to track liveness and interference information.
Either a sparse array with sorted indices or dense array is used.
Other data structures were tried, such as red-black trees or hash
tables, but they were slower. When used for storing constraints, the
indices do not have to be sorted as duplicating elements is okay, but
the speedup from that was not enough to justify the extra complexity.
v2: Add a comment about how to potentially speed it up. But it seems
fast enough even without this change.
v3: Use a custom struct rather than relying on util_dynarray.
v4: Split out functions only used for liveness analysis, rather than the simpler
data structure needed for the register interference matrix. If we need to
optimize liveness, that can follow on after. Also make it for vec8 (Alyssa).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16780>
For the NIR XFB gathering as well as all the Vulkan drivers, buffer
strides in nir_xfb_info are in bytes. When Marek started using
nir_xfb_info for GLSL on radeonsi, he copied directly from the GLSL
struct which has strides in dwords. This inconsistency didn't show up
until I went through and started us using the NIR passes for GL drivers
directly without going through the GLSL structs. We could change the
nir_xfb_buffer_info field to be in dwords to be consistent with
shader_info but that would mean changing all the Vulkan drivers but, for
now, it's easier to always use bytes in nir_xfb_info.
Fixes: 2a22885a45 ("st,nir: Use nir_shader::xfb_info in nir_lower_io_passes")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16819>
A lot of the fields get fully overwritten but outputs/buffers_written
are both bitfields that we set one bit at a time.
Fixes: 7c5dc0b11a ("glsl/nir: Populate nir_shader::xfb_info after linking varyings")
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16819>
We now require C11, and C++ supports static_assert just fine, which is
the only thing this header ever added support for. So let's get rid of
this needless header.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16812>
Since we now depend on C11, we know that we have support for the C99
math functionality. So let's drop the c99_math.h compatibility wrapper,
and just include <math.h> directly.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16812>
These headers use the "restrict" keyword, so they need to include
c99_compat.h in case they get included from C++.
Right now, we include c99_compat.h in many needless places, which saves
us. But we're about to stop doing that.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16812>
We're requiring C11 now, and both "inline" and __func__ is supported
in C++ code as well. So no need for these compatibility-shims anymore.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16812>
Since this logic was written, we've moved to require C11, so this can
now be simplified. First of all, we no longer need to set
__STDC_VERSION__ for C code at all, because the issue that MSVC doesn't
set __STDC_VERSION__ for C99 is longer a concern. Second, we can make
the C++ check unconditional.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16812>
When this landed, the Autotools build system was already removed. Why
was this file added in the first place? Probably a rebase-mistake...
Fixes: 134e750e16 ("i965: extract performance query metrics")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16790>
We don't use this makefile, so there's no point in keeping it in the
repo. It's also a generated one, so it contains a lot of... mess.
Fixes: 536f43cb96 ("freedreno: slurp in afuc")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16790>
The guesses are based on other gpus from the same gfx version. We will
need actual runs on the GPUs to confirm this.
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16810>
dEQP-VK.glsl.builtin.precision_double.determinant.compute.mat3 was
failing because of a CTS bug, which got fixed in the latest update for
all our CI machines.
This commit assumes this got fixed for all families, even the ones we
did not try to run on.
Fixes: 836ce97f5e (ci: bump VK-GL-CTS to 1.3.2.0)
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16810>
The execution time of vkcts has drastically changed with the latest
update, especially for APUs. This commit bumps the timeout to give
them a chance to finish.
Fixes: 836ce97f5e (ci: bump VK-GL-CTS to 1.3.2.0)
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16810>
We don't need to go as far as the fake front thing when MSAA is being used, because the
swapchain (single-sampled) is already decoupled from the app render buffers. But we do
need to direct the frontbuffer flush to the single-sampled back buffer, and then present
the back buffer. We also need to swap the buffers when we do this, so the next blit
targets the former front buffer.
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16227>
ce1a381e57 ("turnip: enable VK_KHR_16bit_storage on A650") determined
that the type of the instr decided the type of the value being stored in
the ".b" case. But it would be surprising if image stores had the type
determine the coordinates' precision instead of the value's, and once we
turned on image instruction precision lowering we ran into asserts.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16616>
A 1D texture operation may need to do a mov to turn a reference to a
channel of an SSA value into a scalar value to be passed as the texture
coordinate (since texture srcs can't do swizzles). Seen in
amnesia-the-dark-descent/low/46.shader_test() for example, where a 1D
texture is used to remap each of r,g,b from a previous texture result.
Besides, the nir_op_is_vec() case will (perhaps surprisingly) look through
a mov, anyway.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16616>
Triggered a BIR validation error, which made debugging a breeze. That validation
pass (dimensionality checks) gets a lot of use, it seems :-)
Fixes:
dEQP-VK.ssbo.layout.2_level_array.std430.row_major_mat4x2_comp_access_store_cols
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16724>