[Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_reloc: Verify relocations with pinned scanout framebuffers
Matthew Auld
matthew.william.auld at gmail.com
Tue Feb 16 16:49:28 UTC 2021
On Tue, 16 Feb 2021 at 14:32, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> In light of the VT-d workarounds, we may introduce padding around the
> scanout vma. This should not affect relocations referencing the scanout
> on !full-ppgtt where we leak the GGTT address of scanout to users.
>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Matthew Auld <matthew.auld at intel.com>
> ---
> tests/i915/gem_exec_reloc.c | 102 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 102 insertions(+)
>
> diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
> index cc9b8cd6d..98960bb84 100644
> --- a/tests/i915/gem_exec_reloc.c
> +++ b/tests/i915/gem_exec_reloc.c
> @@ -26,7 +26,9 @@
>
> #include "i915/gem.h"
> #include "igt.h"
> +#include "igt_device.h"
> #include "igt_dummyload.h"
> +#include "igt_kms.h"
> #include "sw_sync.h"
>
> IGT_TEST_DESCRIPTION("Basic sanity check of execbuf-ioctl relocations.");
> @@ -1286,6 +1288,83 @@ static void concurrent(int i915, int num_common)
> igt_assert_eq(result, 0);
> }
>
> +static uint32_t
> +pin_scanout(igt_display_t *dpy, igt_output_t *output, struct igt_fb *fb)
> +{
> + drmModeModeInfoPtr mode;
> + igt_plane_t *primary;
> +
> + mode = igt_output_get_mode(output);
> +
> + igt_create_pattern_fb(dpy->drm_fd, mode->hdisplay, mode->vdisplay,
> + DRM_FORMAT_XRGB8888,
> + LOCAL_I915_FORMAT_MOD_X_TILED, fb);
> +
> + primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY);
> + igt_plane_set_fb(primary, fb);
> +
> + igt_display_commit2(dpy, COMMIT_LEGACY);
> +
> + return fb->gem_handle;
> +}
> +
> +static void scanout(int i915,
> + igt_display_t *dpy,
> + const struct intel_execution_engine2 *e)
Missing feeding the engine into the execbuf?
I didn't really understand all the specifics of the kms stuff, but in
terms of coverage, I think this makes sense,
Reviewed-by: Matthew Auld <matthew.auld at intel.com>
More information about the Intel-gfx
mailing list