Again sharing the same function across all Intel drivers.
There is still two additional DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM
calls, one in intel/dev and other in perf.
The first one can't call intel_gem_get_context_param() because of the
build order of libs and the second one because it sets the size
parameter.
Will revisit those calls in future but this is already an improvement.
v2:
- using intel_gem_get_context_param() for the recently added query for
I915_CONTEXT_PARAM_PROTECTED_CONTENT
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18974>
This function was returning a int but there was no meaninfull errno
code being returned, also context_id is a uint32_t what would be
problematic if i915 even returned 2147483648(-1).
So here changing the return type and add context_id pointer parameter.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18974>
Color and TS buffers are allocated separately for each etnaviv resource, so
getting the same base and TS buffer at import time is unexpected and a strong
hint at the application doing something wrong, like passing in the same GEM
handle for all planes on a GBM import. Print a warning to give the user some
feedback.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
This adds support for sharing the TS buffer, which up until now has been
an internal implementation detail, with the outside world. This mainly
improves performance with a GPU compositor present, but on i.MX8M also
direct to display use-cases benefit.
The impact of this change depends on the GPU generation:
- old GPUs with a single pipe won't see any difference
- GC2000 can skip the TS resolve in the client and will benefit from a
more efficient blit into the sampler compatible format when the client
buffer contains cleared tiles
- GC3000 can directly sample with TS support, so saves both write and read
memory bandwidth when the client buffer contains cleared tiles
- GC7000 with compression support can keep the client buffer in compressed
format, thus saving both read and write bandwidth even for fully filled
client buffers
- GC7000 coupled to a display unit supporting the compression format (DCSS
on i.MX8M) does not even need to uncompress the render buffer for display
so will see significant bandwidth saving even when GPU compositing is
bypassed
There is a slight complication in that the tile clear color isn't part of
the TS buffer, but is programmed into state registers in the GPU. To handle
this externally shared TS buffers now contain a software metadata area,
where the clear color is stored by the driver, so the receiving end of the
TS buffer can retrieve the clear color from this area.
The compression format is handled in the same way by storing it in the SW
meta area. While we can derive the compression format from the color buffer
format in most cases, some users, like weston, expect that they can "upgrade"
ARGB to XRGB color formats. While this works with plain color formats, as
it's just masking a channel, the compression format differs when alpha is in
use. Receivers of the TS buffer should thus not try to infer the compression
format from the color buffer format, but instead fetch it from the SW meta.
The import/export handling of the TS buffer is modelled after the Intel iris
driver: we add a separate plane for the TS buffer and fold it into the base
resource after the import.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
Unknown modifiers are currently squashed down to linear when transforming
the modifier into our interal layout representation. However, the only real
modifier that we expect to see, which isn't Vivante specific or LINEAR, is
the INVALID modifier. Treat this modifier as linear and reject any other
unexpected modifiers.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
Some display engines are able to resolve fast clear and/or compression
on the fly and need access to the TS buffer to do so. As they might
have restrictions on which memory they can access, allocate the TS
buffer memory from the KMS side when the resource should be SCANOUT
capable.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
The earlier understanding of how tile status tracks the color/depth
surface was wrong and the TS size calculations have long been fixed,
as we now know that color/depth tiles have a fixed size in bytes and
thus don't depend on the surface format. But nobody changed the comment
explaining how TS works, so it's still around as a trap for the reader.
Reword the comment to not confuse people that aren't intimately
familiar with the inner workings of tile status.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9780>
When APIENTRY is not defined, GL/gl.h and GL/glext.h will automatically
include <windows.h>, so we save the macro APIENTRY by push_macro and then
define APIENTRY before include of GL/gl.h and GL/glext.h.
After that we use pop_macro to recover the previous macro again.
Because windows.h is not included by glheader.h, mesa/main/errors.c needs
to include <windows.h> directly to prevent the following error:
errors.c:98:10: error: implicit declaration of function 'OutputDebugStringA' [-Werror=implicit-function-declaration]
98 | OutputDebugStringA(buf);
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Brian Paul brianp@vmware.com
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19472>
Since we now implement events in the GPU we need to be more careful
and insert barriers to honor the dependencies provided by the API
as well as ensuring we are synchronizing these with the compute
queue, since that is how we implement GPU event functionality.
Fixes: ecb01d53fd ("v3dv: refactor events")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19458>
These leaks on device creation failure have been there before, but
were only exposed as CTS failures after the recent event refactoring.
Partially fixes:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic
dEQP-VK.api.object_management.alloc_callback_fail.device
dEQP-VK.api.object_management.alloc_callback_fail.device_group
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19458>
Copied wrong from radeonsi. The registers following the scratch
buffer address are the shader rsrc1/rsrc2. Not the user SGPR0
containing the ring resource word 1.
Fixes: 278e533ec9 ("radv: update scratch buffer registers on GFX11")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19488>
