From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Lionel Landwerlin <lionel.g.landwerlin@intel.com>,
intel-gfx@lists.freedesktop.org
Cc: Ben Widawsky <ben@bwidawsk.net>, Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH 1/4] drm/i915: introduce query info uAPI
Date: Thu, 09 Nov 2017 17:57:01 +0200 [thread overview]
Message-ID: <1510243021.6305.57.camel@linux.intel.com> (raw)
In-Reply-To: <20171108162238.4072-2-lionel.g.landwerlin@intel.com>
On Wed, 2017-11-08 at 16:22 +0000, Lionel Landwerlin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Query info uAPI allows userspace to probe for a number of properties
> of the GPU. This partially removes the need for userspace to maintain
> the internal PCI id based database (as well as code duplication across
> userspace components).
>
> This first version enables engine configuration and features to be
> queried.
>
> Probing is done via the new DRM_IOCTL_I915_QUERY_INFO ioctl which
> takes a query ID as well as query arguments.
>
> Currently only general engine configuration and HEVC feature of the
> VCS engine can be probed but the uAPI is designed to be generic and
> extensible.
>
> Code is based almost exactly on the earlier proposal on the topic by
> Jon Bloomfield. Engine class and instance refactoring made recently by
> Daniele Ceraolo Spurio enabled this to be implemented in an elegant
> fashion.
>
> To probe configuration userspace sets the engine class it wants to
> query (struct drm_i915_gem_engine_info) and provides an array of
> drm_i915_engine_info structs which will be filled in by the driver.
> Userspace also has to tell i915 how many elements are in the array,
> and the driver will report back the total number of engine instances
> in any case.
>
> Pseudo-code example of userspace using the uAPI:
>
> struct drm_i915_query_info info = {};
> struct drm_i915_engine_info *engines;
> int i, ret;
>
> info.version = 1;
> info.query = I915_QUERY_INFO_ENGINE;
> info.query_params[0] = I915_ENGINE_CLASS_VIDEO;
> info.info_ptr_len = 0;
> ret = ioctl(..., &info);
> assert(ret == 0);
>
> engines = malloc(info.info_ptr_len);
> info.info_ptr = to_user_pointer(engines);
> ret = ioctl(..., &info);
> assert(ret == 0);
>
> for (i = 0; i < info.info_ptr / sizeof(*engines); i++)
> printf("VCS%u: flags=%x\n",
> engines[i].instance,
> engines[i].info);
>
> First time with info.info_ptr_len set to zero, so the kernel reports
> back the size of the data to be written into info.info_ptr. Then a
> second time with the info.info_ptr_len field set to the correct
> length.
>
> v2:
> * Add a version field and consolidate to one engine count.
> (Chris Wilson)
> * Rename uAPI flags for VCS engines to DRM_I915_ENGINE_CLASS_VIDEO.
> (Gong Zhipeng)
>
> v3:
> * Drop the DRM_ prefix from uAPI enums. (Chris Wilson)
> * Only reserve 8-bits for the engine info for time being.
>
> v4:
> * Made user_class_map static.
>
> v5:
> * Example usage added to commit msg. (Chris Wilson)
> * Report engine count in case of version mismatch. (Chris Wilson)
>
> v6:
> * Return API to query_info to make it more generic (Lionel)
> * Add query ID & query params (Lionel)
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> Cc: Ben Widawsky <ben@bwidawsk.net>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com>
> Cc: Oscar Mateo <oscar.mateo@intel.com>
> Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
<SNIP>
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2776,6 +2776,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG, i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_QUERY_INFO, i915_query_info_ioctl, DRM_RENDER_ALLOW),
I'm not a fan. This is bit much to the direction of I915_META_IOCTL.
So can we keep this as engine info query without versioning, and if you
need to query something else, lets have another ioctl for that.
(I heard a rumour of this being about RCS topology, which could be in
the engine info.).
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-11-09 15:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-08 16:22 [PATCH 0/4] drm/i915: introduce query information Lionel Landwerlin
2017-11-08 16:22 ` [PATCH 1/4] drm/i915: introduce query info uAPI Lionel Landwerlin
2017-11-09 15:57 ` Joonas Lahtinen [this message]
2017-11-09 16:15 ` Lionel Landwerlin
2017-11-09 17:10 ` Tvrtko Ursulin
2017-11-08 16:22 ` [PATCH 2/4] drm/i915: store all subslice masks Lionel Landwerlin
2017-11-08 16:22 ` [PATCH 3/4] drm/i915/debugfs: reuse max slice/subslices already stored in sseu Lionel Landwerlin
2017-11-08 16:22 ` [PATCH 4/4] drm/i915: expose rcs topology through discovery uAPI Lionel Landwerlin
2017-11-09 17:34 ` Tvrtko Ursulin
2017-11-10 16:37 ` Lionel Landwerlin
2017-11-10 16:47 ` Chris Wilson
2017-11-10 18:29 ` Lionel Landwerlin
2017-11-10 19:03 ` Chris Wilson
2017-11-13 9:14 ` Tvrtko Ursulin
2017-11-13 10:00 ` Lionel Landwerlin
2017-11-13 11:14 ` Chris Wilson
2017-11-08 16:43 ` ✓ Fi.CI.BAT: success for drm/i915: introduce query information Patchwork
2017-11-08 20:04 ` ✓ Fi.CI.IGT: " Patchwork
2017-11-09 11:49 ` [PATCH 0/4] " Lionel Landwerlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1510243021.6305.57.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=ben@bwidawsk.net \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lionel.g.landwerlin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.