[Intel-gfx] [PATCH] igt/gem_create_stolen: Verifying extended gem_create ioctl

[Chris Wilson]

On Sat, Apr 11, 2015 at 05:58:12PM +0530, ankitprasad.r.sharma at intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma at intel.com>
> 
> This patch adds the testcases for verifying the new extended
> gem_create ioctl. By means of this extended ioctl, memory
> placement of the GEM object can be specified, i.e. either
> shmem or stolen memory.
> These testcases include functional tests and interface tests for
> testing the gem_create ioctl call for stolen memory placement
> 
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma at intel.com>
> ---
>  lib/ioctl_wrappers.c      |  47 +++++++
>  lib/ioctl_wrappers.h      |  11 ++
>  tests/Makefile.sources    |   1 +
>  tests/gem_create_stolen.c | 333 ++++++++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 392 insertions(+)
>  create mode 100644 tests/gem_create_stolen.c
> 
> diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> index ff78ef1..9e4b89d 100644
> --- a/lib/ioctl_wrappers.c
> +++ b/lib/ioctl_wrappers.c
> @@ -379,6 +379,53 @@ void gem_sync(int fd, uint32_t handle)
>  	gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
>  }
>  
> +bool gem_create__has_stolen_support(int fd)
> +{
> +	static has_stolen_support = -1;
> +	struct drm_i915_getparam gp;
> +	int val = -1;

I am on a mission at the moment to cache the static queries like this,
i.e.

static int has_stolen_suuport = -1;
if (has_stolen_support < 0) {
	int version = -1;
	gem_get_param(fd, 35 /* CREATE_VERSION */, &version));
	has_stolen_support = version >= 1;
}
return has_stolen_support;

> +
> +	memset(&gp, 0, sizeof(gp));
> +	gp.param = 35; /* CREATE_VERSION */
> +	gp.value = &val;
> +
> +	/* Do we have the extended gem_create_ioctl? */
> +	ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp);

We must have gem_get_param() already?

> +	return val >= 1;
> +}

> +
> +/**
> + * gem_create stolen:
> + * @fd: open i915 drm file descriptor
> + * @size: desired size of the buffer
> + * @flags: desired placement i.e. stolen or shmem
> + *
> + * This wraps the new GEM_CREATE ioctl, which allocates a
> + * new gem buffer object of @size and placement based on @flags.
> + *
> + * Returns: The file-private handle of the created buffer object
> + */
> +

> +uint32_t gem_create_stolen(int fd, int size, uint32_t flags)
> +{
> +	struct drm_i915_gem_create create;

'struct local_i915_gem_create_v2' until headers catch up.

> +igt_main
> +{
> +	int i, fd, gtt_size_total, gtt_size_mappable;
> +	uint32_t devid;
> +
> +	igt_skip_on_simulation();
> +
> +	igt_fixture {
> +		fd = drm_open_any();
> +		devid = intel_get_drm_devid(fd);
> +
> +		drm_intel_get_aperture_sizes(fd, (size_t*)&gtt_size_total,
> +				(size_t*)&gtt_size_mappable);

Oh, we should extend get_aperture_size to include stolen as as well as GTT
aperture and full TT size.

> +		bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
> +		batch = intel_batchbuffer_alloc(bufmgr, devid);
> +	}
> +
> +	igt_subtest("stolen-invalid-flag")
> +		invalid_flag_test(fd);
> +
> +	igt_subtest("stolen-clear")
> +		verify_object_clear(fd);
> +
> +	/*
> +	 * stolen mem special cases - checking for non cpu mappable
> +	 */
> +	igt_subtest("stolen-mmap")
> +		stolen_mmap(fd);

I think changing this and the other negative tests to  "stolen-no-mmap"
to make it clear when running that is a negative test.

> +	igt_subtest("stolen-pwrite")
> +		stolen_pwrite(fd);

pwrite/pread to stolen is just a few lines of kernel to fix, if we want
the api. Considering how difficult it is to access stolen on gen6+, we
probably do.

> +
> +	/* Functional Test - blt copy */
> +	igt_subtest("stolen-copy")
> +		copy_test(fd);

Also test GTT access. You should also hook up gem_concurrent_all to
exercise coherency tests through stolen. That will be not a fun task
though to teach it the restricted API. Similarly, we do want to exercise
set-caching on stolen as well. Our presumption is that it is normal
memory as far as the GPU goes (only the MCH has the filter) and should
verify that all stolen objects actually behave identially.

Similarly, check that we bind stolen to framebuffers (yes, I know the
kernel already does that, but it has been buggy in the past, and it is a
definite use-case for stolen).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre