Both simply take mesa_shader_stage and return it, pipe_shader_type was
renamed to mesa_shader_stage by f972e76148 .
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36918>
The vc4 simulator only allows the memory to be initialized
once, as it would assert if simpenrose_init_hardware_supply_mem
is called twice.
So if a screen_create is called after all previous screens have been
destroyed this raises the assertion, and this happens with CTS
when using a surfaceless target.
To avoid the simulator assertion, we need to guarantee that
simpenrose_init_hardware_supply_mem is only called once
so we never can free the supplied memory to the simulator on
the screen_destroy of the last screen using the simulator.
It can be assumed that the simulator memory will be freed at
the end of the program execution.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36899>
As on Windows, all DLLs are exported use def files, there is no need do __declspec(dllexport) on the function marker.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36863>
v3d_bo_set_reference, v3d_bo_unreference_locked_timed and
v3d_wait_seqno functions available since first v3d commit
45bb8f2957 ("broadcom: Add V3D 3.3 gallium driver called "vc5",
for BCM7268.") are not used since the beginning or since the
removal of its usage at 85f26828fe ("broadcom: only support
v42 and v71") and b225cdcecc ("broadcom/vc5: Update the UABI
for in/out syncobjs").
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36012>
These ops require more than three source values that could result
in readport conflicts, so check the readport configuration
before issuing alu operations and inject copy operations
when conflicts are identified.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36860>
When checking the readport config for a number of sources that
would be used in a multi-slot instruction, then return the index
of the source for which readport allocation fails.
With that we can later add a mov instruction to change the source
channels configuration.
In addition pass a std::array instead of a C-array to make the interface
more c++-like and prepare for the next patch.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36860>
Now that we have pan_image_test_modifier_with_format(), use it do our
native modifier check. This involves fully describing the YUV lowering
even for formats that don't have a native YUV-as-RGB fallback.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35761>
If the plane formats are __DRI_IMAGE_FORMAT_NONE (AKA PIPE_FORMAT_NONE),
we can't lower the planar-YUV. I guess this code relies on
::is_format_supported(PIPE_FORMAT_NONE, PIPE_BIND_SAMPLER_VIEW)
returning false, but it's not obvious to me that it should, and panfrost
has been returning true on this one for quite a long time. It could be
that panfrost is wrong, and this case should be rejected, but it's just
as simple to reject the lowering if the plane format is
__DRI_IMAGE_FORMAT_NONE instead of deferring this check to the driver,
because ultimately we can't lower NV15/NV20 unless the driver supports
NV15/NV20 or R10_G10B10_{420,422}.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35761>
MTK_TILED is not in the native_mods list, so drop the check we had in
this loop.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35761>
We can just place the set structures inside nir_block.
This reduces the number of ralloc calls by 6.7% when compiling Heaven
shaders with radeonsi+ACO using a release build (i.e. not including
nir_validate set allocations, which are also removed).
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36728>
We can use _mesa_hash_table_init instead of _mesa_hash_table_create.
It doesn't have to be allocated.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36728>
it always returns true because it no longer allocates anything
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36728>
_mesa_hash_table_init & _mesa_hash_table_fini (and equivalents) is
the preferred way to set up hash tables.
This adds missing "init" and "fini" functions.
_mesa_string_hash_table_create is also changed to non-inline.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36728>
it always returns true because it no longer allocates anything
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36728>
which was deprecated in 0.47. This doesn't change behavior, just shuts
up warnings.
meson.build:105: WARNING: Project targets '>= 1.4.0' but uses feature deprecated since '0.47.0': build_always arg in custom_target. combine build_by_default and build_always_stale instead.
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Pohsiang (John) Hsu <pohhsu@microsoft.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36891>
../../src/gallium/winsys/d3d12/wgl/d3d12_wgl_framebuffer.cpp:86:22: warning: comparison of integer expressions of different signedness: 'int' and 'const uint32_t' {aka 'const unsigned int'} [-Wsign-compare]
86 | for (int i = 0; i < num_buffers; ++i) {
| ~~^~~~~~~~~~~~~
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36864>
This implements support for Decode processing allowing to perform
processing operation on the decoded picture in one single call without
having to use separate processing context.
This also implements the same functionality for encoding, which is
useful to perform conversion from RGB to YUV in a single call, and it
allows us to properly support the conversion inside encoder (eg. EFC on
AMD).
For Encode processing the additional output buffer is required same as
with Decode processing, but driver may not use it to perform the
conversion (in case where the conversion can be done by the encoder hw).
This means the contents of the additional buffer is undefined, and
application should not rely on the buffer actually containing output
picture of the conversion.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36755>
