These are required to support rusticl.
Signed-off-by: Italo Nicola <italonicola@collabora.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22210>
enable RGBA/ARGB format on gfx940 to aid RGBA/ARGB conversion after decode
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22158>
propogate region of interest co-ordinates for crop region decode
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22158>
when decoding without ROI/FC feature reset the registers to default value.
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22158>
select appropriate jpeg register version for gfx940
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22158>
enable ARGB/RGBA conversion feature on JPEG 4.0.3
v2: fix regression caused due to uninitialized variable
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22158>
set the crop region and enable the feature if requested
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22158>
update the register version and select appropriate registers during decoder create
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22158>
Signed-off-by: Sathishkumar S <sathishkumar.sundararaju@amd.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22158>
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>
