Other than nouveau, every single Gallium driver relies on
u_pipe_screen_get_param_defaults to get the default values of CAPs.
For the driver, this is much more concise. Unsupported new features -- or
supported features that virtually all Gallium drivers support -- do not need to
written out explicitly. Their absence (or presence) is implied as the default.
If there's any doubt over whether the CAP is exposed, it's easy to check in
u_pipe_screen_get_param_defaults.
For the Gallium tree in general, this brings a number of benefits:
* Unused CAPs are easy to delete, because there is only a single place
(u_pipe_screen_get_param_defaults) where they are referenced and need to be
deleted from.
* New CAPs are easy to introduce, for the same reason.
* It's straightforward to audit which drivers support (or don't support) a given
CAP by grepping for the name (for example, when determining whether a CAP is
unused and can be garbage collected, or a CAP is so widely supported that it
can be made default.). You still need to check the source code in case it's
conditionally exposed (common for layered drivers) but the search space is
limited to drivers that reference the CAP by name.
Unfortunately, all of these benefits rely on all Gallium drivers cooperating.
The status quo is much less nice:
* Unused CAPs need to be deleted both from common code, and also specially from
nouveau. Why is nouveau special?
* New CAPs need to be added both to common code, and also specially to nouveau.
Again, why is nouveau special?
* When grepping for CAPs, nouveau (only) needs to be ignored, since it's
spurious. Unless sometimes it's not, in which case you need to open nouveau
source code anyway to check.
Compounding on the fun, you have to do the special nouveau step twice, once for
nvc0 and once for nv50.
Why might it be benefical to list CAPs explicitly instead of relying on the
defaults?
* Maybe easier auditing nouveau driver for CAP correctness? In practice this has
not been an issue for any of the drivers I've worked on, especially because
the defaults are quite reasonable.
* Maybe forcing people adding CAPs to think about nouveau specially? This isn't
fair to the tree in general, why should nouveau get this special
treatment? Instead, CAPs are generally added to gate functionality that may
not be supported on all drivers, and the default is disabling the new
functionality until a developer for a given driver can wire it up. There's
already no expectation that the person adding CAPs needs to also add the
functionality to nouveau (if that's even possible) -- unless the CAP is being
added for the particular nouveau's benefit of course -- so this isn't helpful.
* Maybe forcing people removing CAPs to think about nouveau specially? Similar
issues apply here, and it's not clear how this would even work.
* Maybe keeping novueau developers aware of CAP churn? Again nouveau should not
be special here and it isn't sustainable to do this for every driver. So, if
this is something that nouveau developers want to do -- and they choose not to
follow Gallium-tagged merge requests -- then the git log of
src/gallium/include/pipe/p_defines.h or indeed
src/gallium/auxiliary/util/u_screen.c may be consulted.
So, without an excellent reason why nouveau should be treated specially, and
with several reasons why it should not, let's bring nouveau in line with the
rest of Gallium and rely on the defaults.
I've left in CAPs with attached comments even when they are returning the
default value to preserve information from before the commit. Otherwise, this
commit aims to remove explicit cases that match the default value, as other
drivers generally aim to do.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22245>
The glsl compiler has been reworked to avoid passing gl_context around
so that we can avoid expensive recompiles across the code base for
minor changes. This helper will help us avoid passing gl_context around
where its otherwise unrequired.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22305>
This is to inform you of some planned downtime in the LAVA lab as follows:
Start: 2023-04-06 07:30 GMT
End: 2023-04-06 09:00 GMT
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22185>
Rename radv_layout_fmask_compressed and make it return an enum. We will
add partial compression (fmask decompressed and not expanded) in a
following commit.
Drop the check for VK_IMAGE_USAGE_STORAGE_BIT and
VK_IMAGE_USAGE_TRANSFER_DST_BIT. When transitioning to
VK_IMAGE_LAYOUT_GENERAL, we should decompress and expand FMASK even when
those usage bits are not set.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21615>
It's been popular for flakes due to oomkilling or kernel kmalloc failure
recently. Is it ultimately the source of running out of memory? Who
knows, but hopefully it's at least a big part of the problem.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22083>
This is no longer emitted by nir_to_tgsi, so let's drop it. This unlocks
some more TGSI DCE, since now all instructions have a single dest, but
that's a project for another day.
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/22083>
All drivers should now be using the appropriate NIR lowering, so we can
drop this pile of code.
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/22083>
All the users should now be calling the appropriate NIR lowering function.
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/22083>
The GLSL frontend was already lowering 32-bit frexp, so only 64-bit frexp
is possible as an op in the incoming NIR. However, svga and nouveau don't
set PIPE_SHADER_CAP_DFRACEXP_DLDEXP_SUPPORTED, leaving just r600's
non-default TGSI mode potentially using it.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22083>
Needed for Vulkan, and for dropping GLSL frontend lowering for the deqp
coverage override case.
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/22083>
This will enable GLSL to drop its frexp lowering in the frontend.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22083>
This would be desired for NVK using this backend, but also for getting
lowering out of the GLSL frontend.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22083>
This was needed for nir_lower_frexp, but it's a win anyway. shader-db
results:
total gpr in shared programs: 1143621 -> 1143502 (-0.01%)
gpr in affected programs: 33918 -> 33799 (-0.35%)
total instructions in shared programs: 7829415 -> 7820124 (-0.12%)
instructions in affected programs: 1204967 -> 1195676 (-0.77%)
total bytes in shared programs: 71802760 -> 71717352 (-0.12%)
bytes in affected programs: 11031888 -> 10946480 (-0.77%)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22083>
We don't have softfp64 for frexp, it has been lowered in GLSL up until
now. I didn't bother splitting out 32 from 64 because it's not worth any
effort.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22083>
This is generated by nir_lower_frexp, and if we leave fisfinite in place
then the late algebraic pass lowering it to this pattern will cause an
un-lowered fabs64 to be emitted.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22083>
We previously had GLSL do ldexp lowering to bitops, but NIR can do it
instead. It's tempting to just pass the NIR op through to the host Vulkan
driver, but to do that we'd need to split up NIR's flag between 32 and
64-bit support, and that's not worth anyone's time for an op we've never
seen used.
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22083>
if shaders are found in the app cache above, execution will goto done:
and the nir must still be freed
Fixes: 03d2bd6042 ("radv: ensure to retain NIR shaders for GPL libs found in the cache")
fixes#8786
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22317>
Move deflate and put to the queue for the blob cache case. This moves
the overhead out of the app thread when storing new shaders.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22248>
If we move the blob-cache path into the async queue, then
path_init_failed is no longer a good way to check if puts
should be a no-op. But fortunately checking if the queue
is initialized is, and is a more obvious check because
what it is guarding is a util_queue_add_job().
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22248>
Add an explicit enum for the DISK_CACHE_NONE type so that we don't
confuse with the MULTI_FILE case on android when the blob-cache is
used.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22248>
MTL support fp64, but not int64. The fsign(double(x))*FOO optimization
would try to use a 64-bit int xor operation to conditionally toggle
the sign bit off the result.
Since this only affects high bit of the result, we can do a 32-bit
move of the low dword, and a 32-bit xor on the high dword.
Fixes dEQP-VK.spirv_assembly.instruction.compute.float_controls.fp64.input_args.modf_denorm_flush_to_zero
on MTL.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22259>
