All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenneth Graunke <kenneth@whitecape.org>
To: mesa-dev@lists.freedesktop.org
Cc: Oscar Mateo <oscar.mateo@intel.com>,
	Ben Widawsky <ben@bwidawsk.net>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
	Intel-gfx@lists.freedesktop.org, "Rogozhkin,
	Dmitry V" <dmitry.v.rogozhkin@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	Jon Bloomfield <jon.bloomfield@intel.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	intel-vaapi-media@lists.01.org, "Gong,
	Zhipeng" <zhipeng.gong@intel.com>
Subject: Re: [RFC 1/2] drm/i915: Engine discovery uAPI
Date: Tue, 18 Apr 2017 22:22:18 -0700	[thread overview]
Message-ID: <6570224.bZGvjJtkdM@eiger> (raw)
In-Reply-To: <20170418165615.27666-2-tvrtko.ursulin@linux.intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 1345 bytes --]

On Tuesday, April 18, 2017 9:56:14 AM PDT Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> Engine discovery uAPI allows userspace to probe for engine
> configuration and features without needing to maintain the
> internal PCI id based database.

I don't understand why I would want to query the existence of engines
from the kernel.  As a userspace driver developer, I have to know how to
program the specific generation of hardware I'm on.  I better know what
engines that GPU has, or else there's no way I can competently program it.

In Mesa, we recently imported libdrm and deleted all the engine checks
(a460e1eb51406e5ca54abda42112bfb8523ff046).  All generations have an
RCS, Gen6+ has a separate BLT, and we don't need to use the others.
It's completely statically determinable with a simple check.  Runtime
checks make sense for optional things...but not "is there a 3D engine?".

Plus, even if you add this to the kernel, we still support back to 3.6
(and ChromeOS needs us to continue supporting 3.8), so we won't be able
to magically use the new uABI - we'd need to support both.  Which, if
the point is to delete code...we'd actually have /more/ code for a few
years.  Or, we could not use it...but then nobody would be testing it,
and if a bug creeps in...that pushes it back more years still.

Sorry :(

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

  parent reply	other threads:[~2017-04-19  5:22 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-18 16:56 [RFC 0/2] New engine discovery and execbuffer2 engine selection uAPI Tvrtko Ursulin
2017-04-18 16:56 ` [RFC 1/2] drm/i915: Engine discovery uAPI Tvrtko Ursulin
2017-04-18 20:13   ` Chris Wilson
2017-04-24  8:07     ` Tvrtko Ursulin
2017-04-19  5:22   ` Kenneth Graunke [this message]
2017-04-24  8:26     ` [Mesa-dev] " Tvrtko Ursulin
2017-04-19  8:32   ` Gong, Zhipeng
2017-04-27  9:10   ` [RFC v2 " Tvrtko Ursulin
2017-05-18 14:57     ` [RFC v3 " Tvrtko Ursulin
2017-06-26 15:47       ` [RFC v4 " Tvrtko Ursulin
2017-06-28 11:27         ` Chris Wilson
2017-06-28 13:15           ` Tvrtko Ursulin
2017-06-28 13:19             ` Tvrtko Ursulin
2017-06-28 13:21             ` Chris Wilson
2017-06-28 11:33         ` Chris Wilson
2017-06-28 15:30         ` [RFC v5 " Tvrtko Ursulin
2017-04-18 16:56 ` [RFC 2/2] drm/i915: Select engines via class and instance in execbuffer2 Tvrtko Ursulin
2017-04-18 21:10   ` Chris Wilson
2017-04-24  8:36     ` Tvrtko Ursulin
2017-04-27  9:10   ` [RFC v2 " Tvrtko Ursulin
2017-04-27  9:25     ` Chris Wilson
2017-04-27 10:09       ` Tvrtko Ursulin
2017-04-27 10:26         ` Chris Wilson
2017-05-17 15:40       ` [RFC v3] " Tvrtko Ursulin
2017-05-17 16:44         ` Chris Wilson
2017-05-18 13:30           ` Tvrtko Ursulin
2017-05-18 13:50             ` [Intel-gfx] " Chris Wilson
2017-05-18 10:55         ` Joonas Lahtinen
2017-05-18 11:10           ` Chris Wilson
2017-05-18 12:13             ` Tvrtko Ursulin
2017-05-18 12:24               ` Chris Wilson
2017-05-18 13:06                 ` Tvrtko Ursulin
2017-05-18 13:37                   ` Chris Wilson
2017-05-18 16:20                     ` Tvrtko Ursulin
2017-05-18 17:00                       ` [Intel-gfx] " Chris Wilson
2017-05-24 11:28                         ` Tvrtko Ursulin
2017-05-25 14:14                           ` [Intel-gfx] " Chris Wilson
2017-06-15  8:08                             ` Tvrtko Ursulin
2017-05-18 14:10                   ` [Intel-gfx] " Emil Velikov
2017-05-18 14:55                     ` Tvrtko Ursulin
2017-05-18 14:58         ` [RFC v4 2/2] " Tvrtko Ursulin
2017-05-18 15:13           ` Chris Wilson
2017-06-26 15:48           ` [RFC v6 " Tvrtko Ursulin
2017-04-18 17:12 ` ✗ Fi.CI.BAT: failure for New engine discovery and execbuffer2 engine selection uAPI Patchwork
2017-04-27 10:16 ` ✓ Fi.CI.BAT: success for New engine discovery and execbuffer2 engine selection uAPI (rev3) Patchwork
2017-05-18 17:11 ` ✓ Fi.CI.BAT: success for New engine discovery and execbuffer2 engine selection uAPI (rev6) Patchwork
2017-06-26 16:04 ` ✓ Fi.CI.BAT: success for New engine discovery and execbuffer2 engine selection uAPI (rev8) Patchwork
2017-06-28 15:47 ` ✗ Fi.CI.BAT: failure for New engine discovery and execbuffer2 engine selection uAPI (rev9) Patchwork

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=6570224.bZGvjJtkdM@eiger \
    --to=kenneth@whitecape.org \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=ben@bwidawsk.net \
    --cc=daniel.vetter@intel.com \
    --cc=dmitry.v.rogozhkin@intel.com \
    --cc=intel-vaapi-media@lists.01.org \
    --cc=jon.bloomfield@intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=oscar.mateo@intel.com \
    --cc=tursulin@ursulin.net \
    --cc=tvrtko.ursulin@intel.com \
    --cc=zhipeng.gong@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.