In order to return correct offsets, strides and possibly other
parameters. This is relevant for formats like NV12 and P010 where
the second plane, when produced by the Intel VAAPI decoder, uses the
same FD like the first one, but with an offset.
Right now there are only two modifiers with well defined indices
of auxiliary planes for semi-planar formats according to the local
copy of drm_fourcc.h, `I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS` and
`I915_FORMAT_MOD_4_TILED_MTL_MC_CCS`, sharing the same layout.
Assume that future `MC_CCS` modifiers will get defined accordingly
for now.
Cc: mesa-stable
Tested-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9952
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25603>
Follow up of "egl/drm: get compatible render-only device fd for kms-only
device". Now we can properly error out when we don't find the EGLDevice
in _eglFindDevice().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
Things have been working by accident for split display/render SoCs when
using the GBM platform.
The device fd given to the GBM platform may be associated with a
KMS-only device, so _eglFindDevice() should find nothing (because the
global EGLDevice list only has render-capable devices). The only thing
making it work is that we don't error out when we go through the
EGLDevice list and can't find the device we are looking for. We simply
return the last EGLDevice from the list.
This patch fixes that. Now we look for a compatible render-only device
for the KMS-only in the GBM platform.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
Add helper function to check if a device is render-capable.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
Since commit "pipe-loader: add
pipe_loader_get_compatible_render_capable_device_fd()", we have a
function to query a render-only driver that is available and is
compatible with the KMS-only device.
So start to use it, instead of selecting whatever render-only driver is
available to use.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
With this change we are able to query the render node fd of a
render-only device compatible with a given KMS-only device (at the
egl/dri2 level).
It uses pipe_loader_get_compatible_render_capable_device_fd(), which was
added in commit "pipe-loader: add
pipe_loader_get_compatible_render_capable_device_fd()".
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
pipe_loader_get_compatible_render_capable_device_fd() receives the fd of
a KMS-only platform device, find a compatible render-only device that is
available and returns the fd of its DRM render node.
This function will be helpful to fix a long standing issue that is
preventing us to add support for EGL_EXT_device_drm_render_node for
split display/render SoCs. And it will also help KMSRO to select a
render-only driver that we are sure that is compatible, because
currently KMSRO uses whatever render-only driver is available.
In sort, in the EGL GBM platform case, the GBM device may be created
with a KMS-only device. The information of what render driver will be
selected by KMSRO is not available before creating the EGLDevice global
list. Without this information we don't have a render node to use in the
EGL_EXT_device_drm_render_node query. We've tried to fix this before,
but failed. See [1-2].
For the moment, this function only works for platform KMS-only devices.
For other types of KMS-only devices, we'll need to add more heuristics.
[1] Detailed explanation of the issue:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/5591
[2] Previous attempt to fix:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12796
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
In a later commit in this series, we'll need to open the first supported
render-only platform device that we can find.
In order to avoid calling loader_open_render_node_platform_device()
multiple times (what is quite expensive), change this function to take a
driver list (instead of a single driver name) as parameter.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
This function ignore devices that are not on the platform bus. So rename
it to better reflect that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24825>
Summary:
1. hide those extensions for vtest since there's no export support
2. do block waiting upon export without implicit fencing support
Fixes: 68a478870d ("venus: expose KHR_external_fence/sempahore_fd extensions")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25633>
Heuristic-based optimization throttling CCS work (async compute).
Without throttling, background compute work consumes all threads,
deminishing performance gains by running dispatch in parallel with
3D work.
Optimization is heuristics based, meaning a workload might slow
down when using async compute.
Best value: PixelAsyncComputeThreadLimit = 4. On DG2, this
equates to a max CCS thread occupancy of 37.5%.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25508>
Make sure to zero the shared TS metadata memory. Without this invalid
TS data may be mistaken as being valid, causing GPU hangs.
CC: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25751>
The padded width/height is stored in samples, while the blit box
dimensions need to be specified in pixels. Use the unpadded
width/height of the resource levels to generate the blit box
dimensions used to copy a resource. The blit code already extends
those sizes to the padded sizes when necessary and possible.
Fixes crashes in some piglit tests with MSAA active.
CC: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25751>
Fix defect reported by Coverity Scan.
Evaluation order violation (EVALUATION_ORDER)
write_write_typo: In opcode = opcode = desc->opcode_first, opcode is
written twice with the same value.
Fixes: 3b20208f03 ("broadcom/qpu: add pack/unpack support for v71")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25735>
Previously all items on a timeline row would have the same name. This
change uses the tracepoint names to put into the timeline instead.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Felix DeGrood <felix.j.degrood@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25730>
The driver glue doesn't have access to that information in a
centralized place. If you want to generate perfetto iid, you need
access to all names.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Felix DeGrood <felix.j.degrood@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25730>
Useful to figure out what's the tracepoint name you're implementing.
We'll use this in the intel perfetto integration glue to index into an
array of perfetto iid.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Felix DeGrood <felix.j.degrood@intel.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25730>
There is not real need to use the spirv-linker here at all,
we can just read all the CL C files into one buffer, then compile
that buffer in a single pass.
This worksaround an issue seen with llvm17 and opaque pointers
and the spirv linker.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25759>
This is what the kernel reports and what PAL seems to be doing.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25578>
This should be large enough for all engines.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25578>
We overalign it anyway, so there is no change in behavior.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25578>
No change in behavior. The previous overalignment is preserved.
It sets ib_pad_dw_mask sooner.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25578>
If a value would be used e.g. as Rn.x___ and also as Rn.xy__, in two
different instructions , then the first use was removing the group
property if Rn.x, which then broke the use in the second case, because
RA didn't see anymore, that Rn.x and Rn.y must be allocated with the
same register ID "n".
Fixes: c23604324b (r600/sfn: copy-propagate single source texture values)
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9998
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25741>
For images of size 32768 × 32768 (which NVK allows), the linear image
ends up being 4GB which overflows the uint32_t size as well as some of
our alignment calculations.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25729>
