I incorrectly assumed the API side defines how those values are sized, but
it's actually the GPU's pointer size. The API is simply reduced to 32 bit
ranges in 32 bit mode, but has to still pass in 64 bit values to the GPU.
Also use explicit types in a couple of places to prevent such mistakes in
the future.
Fixes: 204c287327 ("rusticl/kernel: properly handle grid and offsets being usize")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29527>
Usually applications will submit one buffer per slice. Instead of
sending it to driver in parts, send all submitted buffers at the
end of vlVaRenderPicture.
Avoids excessive reallocations in driver.
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29131>
Right now we have some HW-dependant constants that we are accessing
using the same mechanism that some hw-dependant functions, through a
macro (V3DV_X macro).
But this means that each time that we need to get those constant
values, we need to do a hw version check. Also, right now both the
macro and the defines with each HW value are duplicated on v3d and
v3dv. Also that macro is ugly and has a ugly name.
This commit moves those values to the already common v3d_device_info
structure.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29535>
For extensions in the official CL headers this isn't all that important as
those are quite stable, but once we implement ext extensions it's better
to catch changes at compile time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29526>
If a buffer upload replaces the entire valid_buffer_range, we can
promote the update to DISCARD_WHOLE_RESOURCE. This helps badly behaved
apps which constantly upload to the same offset (but are overwriting
the entire valid range each time).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29507>
Allow drivers to limit the amount of replacement buffers created, to
avoid runaway memory scenarios.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29507>
This is mostly a revert of cc78a42577 but we leave the meson tools
option as there is now a disassem tool.
This standalone compiler is unmaintained. The replacement is using
drm_shim which goes through the maintained/tested path.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29494>
Iris calls iris_resource_get_param with PIPE_RESOURCE_PARAM_STRIDE
internally now when exporting memory objects. OpenCL's gl_sharing allows
to export buffers as well, which do not have strides.
This fixes the assert being hit there for buffers.
Fixes: 831703157e ("iris: Use resource_get_param in resource_get_handle")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29501>
Macro values that define values for different HW generations should
use the V3DV_X helper instead of being defined under a V3D_VERSION #if
condition.
Without this change, the original V3D_CLE_READAHEAD and
V3D_CLE_BUFFER_MIN_SIZE definitions used were only working for 4.2 HW.
For the 7.1 HW (RPi5) the 4.2 definitions were applied.
The CLE MMU errors were hidden as they were reported at dmesg as
"MMU error from client PTB (1) at 0x1884200, pte invalid" instead of
client CLE. So fixes all v3d dmesg warnings for PTB MMU errors on RPi5.
With this change we really don't need different functions per HW generation,
so we rename back file v3dx_cl.c to v3d_cl.c. As before, we can use
only the packets definitions for 4.2 HW as they use the same opcode as 7.1 HW.
Fixes: 11dce2ac81 ("v3d: fix CLE MMU errors avoiding using last bytes of CL BOs.")
Fixes: e2c624e74e ("v3d: Increase alignment to 16k on CL BO on RPi5")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29496>
Compared to vcn4, qp map unit is a 32bit number,
vcn5 uses 16bit integer number, in addition to
that it has 2 unit alignment requirement(32 bit
alignment) and each qp value needs left shift 7 bits.
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29423>
Have logic to handle tile allocation
according to vcn5's capability, if the
tile allocation is out of the limit, will
re-adjust the tile parameters.
re-construct frame header and obu instruction
logic. And add av1 encode params requried
for vcn5.
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29423>
Update header files for av1 tile and delta qp.
vcn5 needs driver and applcation to manage that
while in vcn4 they are managed in FW.
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29423>
We are writing 32-bit register value to buffer and were reading back
64-bit value back into two register. We don't need to read the second
register in this case.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29389>
this allows amd drivers to disable llvm support while still allowing
llvmpipe/lavapipe to be built
by disabling llvm support in amd drivers, the load times for these drivers
decreases by 5-10ms
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28969>
Otherwise we run into following build error on Android:
ld.lld: error: undefined symbol: galliumvk_driver_extensions
Fixes: cfa955ed78 ("glx/egl: fix LIBGL_KOPPER_DISABLE")
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29475>
Up to now preferred SLM size was being set to maximum preferred SLM
size for GFX 12.5 platforms and to workgroup SLM size for Xe2 but
neither of those values are the optimal.
The optimal value is:
<number of workgroups that can run per subslice> * <workgroup SLM size>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28910>
Xe2 has 2 requirements for preferred SLM size:
- this value needs to be >= then SLM size
- this value must be less than shared SLM/L1$ RAM in the sub-slice of platform
Also Xe2 don't have the special '0' encode that sets preferred SLM
allocation size to the maximum supported.
So here setting a value that is equal or larger than SLM size.
It was always setting SLM_ENCODES_128K for LNL A0 stepping probably
because of Wa_16018610683 but this restriction applies to all Xe2
platforms, also because of the first restriction mentioned here
this workaround is not being properly implemented, will fix that
in the next patch.
We should have a formula to calculate a preferred SLM allocation size
for gfx125 and Xe2 platfoms but until that this is enough to fix at
least the applications and tests below on LNL:
- GFXBench Aztec Ruins VK
- GravityMark VK
- Wildlife Extreme VK
- 5 crucible tests
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28910>
This functions were inlined in a header and duplicated between brw and
elk.
That would be enough reasons to move to a C file but next patches
will add more code to support Xe2 platforms, what would cause more
code to be inlined, duplicating even more code and increasing lib
size.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28910>
libgalliumvl_stub was added so not all frontends have to link in full
video accleration support, shaving off around 100kB of binary size.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26680>
Fixes compiling rusticl with certain configurations
Cc: mesa-stable
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26680>
This way frontends can simply link against the stub, but get the full
version if it's actually required (e.g. for radeonsi).
Cc: mesa-stable
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26680>
