All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>, Takashi Iwai <tiwai@suse.de>,
	Intel graphics driver community testing & development
	<intel-gfx@lists.freedesktop.org>,
	Timo Aaltonen <timo.aaltonen@canonical.com>,
	dri-devel@lists.freedesktop.org,
	Carl Zhang <carl.zhang@intel.com>,
	Stephane Marchesin <stephane.marchesin@gmail.com>,
	Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
Date: Mon, 4 Feb 2019 10:07:03 +0100	[thread overview]
Message-ID: <20190204090703.GI3271@phenom.ffwll.local> (raw)
In-Reply-To: <154927064436.3692.9541101262639655442@jlahtine-mobl.ger.corp.intel.com>

On Mon, Feb 04, 2019 at 10:57:24AM +0200, Joonas Lahtinen wrote:
> Quoting Joonas Lahtinen (2019-01-15 16:47:27)
> > Hi all,
> > 
> > I would like to have some Acked-by's from you, the distro media
> > folks Cc'd here, to document your intent to start using Intel's
> > new media driver[1]. So if you recognize yourself (or are otherwise
> > interested), please read on.
> > 
> > TL;DR Distro folks, please give your Acked-by on patch [5/6]
> 
> A gentle reminder, I'm still looking to hear back from Stephane
> and Dave.
> 
> We'd like to have this included in the final 5.1 drm-intel-next
> pull request this week.
> 
> If there are no further comments by Wed, I will conclude that we
> have reached a silent agreement, and merge this to give enough
> time for Rodrigo to send the PR.

Maybe should add that ubunut/suse folks seem ok. Also, it's for libva, in
the past that's been very far down the list of contentious topics. Mostly
positive meh seems plenty good enough feedback I think.
-Daniel

> 
> Regards, Joonas
> 
> > I believe most are already aware of the situation that Intel
> > is moving to the new codebase for libva backend to support new Intel
> > integrated graphics devices. The existing intel-libva-driver will
> > be continue to be be supported for pre-Icelake platforms (<Gen11).
> > Icelake and further platforms will only be supported from the
> > new codebase.
> > 
> > There's the complication that some Icelake features of the new
> > driver will require new kernel uAPIs to work... But the new driver
> > has not yet been well-established in the community from perspective
> > of fulfilling [2]. This is very much due to the demand being low
> > as Icelake is not widely available yet. So it's bit of a chicken
> > and egg problem as we have a new platform *and* a new codebase for
> > it simultaneously.
> > 
> > Ahead of that community adoption, to ensure that Icelake has good
> > kernel support from day one, we'd like to merge kernel support for
> > the parts that have functional effect (this series). This is to
> > avoid the scenario where end users have to update their distro
> > kernels, like happened with Skylake.
> > 
> > So if I could get Acked-by's from distro folks on the patch [5/6] that
> > adds the new uAPI. That would document their intent to become an active
> > user of the media-driver[1]. If that happens in the next week or two,
> > it would mean that Icelake hardware features would be supported in
> > kernel version 5.1 fully from kernel driver point of view.
> > 
> > The new uAPI is needed to make VME feature functionally work
> > on Icelake. It's pretty much a simple enable/disable switch for
> > hardware configuration that only includes hardware slices compatible
> > with the VME workload. So it's currently limited to the required on/off
> > choice to keep things straightforward. The uAPI can be extended in the
> > future for possible performance gains for more fine-grained control.
> > 
> > VME is shared function to handle motion estimation. One intended
> > usercase is in Hierarchical Motion Estimation (HME) media kernel. It
> > provides a bigger search range with reduced cost for the search. HME
> > should improve the encode quality with scenarios where the video has
> > a lot of motion in it. Carl (Cc'd) can provide more details if needed.
> > 
> > The respective IGT tests are reviewed and can be found at:
> > 
> >   https://patchwork.freedesktop.org/series/49190/
> > 
> > The userspace changes are reviewed and rebased here:
> > 
> >   https://github.com/intel/media-driver/pull/271
> >   https://github.com/intel/media-driver/pull/463
> > 
> > Best Regards, Joonas Lahtinen
> > 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Timo Aaltonen <timo.aaltonen@canonical.com>
> > Cc: Takashi Iwai <tiwai@suse.de>
> > Cc: Stephane Marchesin <stephane.marchesin@gmail.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > 
> > PS. This series might result in some CI failures reported as it adds new uAPI
> >     and Patchwork / CI synchronization of tests and kernel is currently WIP.
> > 
> > [1] https://github.com/intel/media-driver
> > [2] https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
> > 
> > Lionel Landwerlin (2):
> >   drm/i915: Record the sseu configuration per-context & engine
> >   drm/i915/perf: lock powergating configuration to default when active
> > 
> > Tvrtko Ursulin (4):
> >   drm/i915/execlists: Move RPCS setup to context pin
> >   drm/i915: Add timeline barrier support
> >   drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
> >   drm/i915/selftests: Context SSEU reconfiguration tests
> > 
> >  drivers/gpu/drm/i915/i915_drv.h               |  14 +
> >  drivers/gpu/drm/i915/i915_gem_context.c       | 354 ++++++++++++-
> >  drivers/gpu/drm/i915/i915_gem_context.h       |  10 +
> >  drivers/gpu/drm/i915/i915_perf.c              |  13 +-
> >  drivers/gpu/drm/i915/i915_request.c           |  13 +
> >  drivers/gpu/drm/i915/i915_request.h           |  10 +
> >  drivers/gpu/drm/i915/i915_timeline.c          |   3 +
> >  drivers/gpu/drm/i915/i915_timeline.h          |  27 +
> >  drivers/gpu/drm/i915/intel_lrc.c              | 100 ++--
> >  drivers/gpu/drm/i915/intel_lrc.h              |   2 +
> >  .../gpu/drm/i915/selftests/i915_gem_context.c | 481 ++++++++++++++++++
> >  .../gpu/drm/i915/selftests/mock_timeline.c    |   2 +
> >  include/uapi/drm/i915_drm.h                   |  64 +++
> >  13 files changed, 1056 insertions(+), 37 deletions(-)
> > 
> > -- 
> > 2.17.2
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-02-04  9:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-15 14:47 [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver Joonas Lahtinen
2019-01-15 14:47 ` [PATCH 1/6] drm/i915/execlists: Move RPCS setup to context pin Joonas Lahtinen
2019-01-15 14:47 ` [PATCH 2/6] drm/i915: Record the sseu configuration per-context & engine Joonas Lahtinen
2019-01-15 14:47 ` [PATCH 3/6] drm/i915/perf: lock powergating configuration to default when active Joonas Lahtinen
2019-01-15 14:47 ` [PATCH 4/6] drm/i915: Add timeline barrier support Joonas Lahtinen
2019-01-15 14:47 ` [PATCH 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only) Joonas Lahtinen
2019-01-21 12:56   ` Timo Aaltonen
2019-01-21 21:33   ` Takashi Iwai
2019-01-15 14:47 ` [PATCH 6/6] drm/i915/selftests: Context SSEU reconfiguration tests Joonas Lahtinen
2019-01-15 15:57 ` ✗ Fi.CI.BAT: failure for Add uAPI to support ICL VME hardware for new media-driver Patchwork
2019-02-04  8:57 ` [PATCH 0/6] " Joonas Lahtinen
2019-02-04  9:07   ` Daniel Vetter [this message]
2019-02-05  4:16     ` Stéphane Marchesin
2019-02-05  9:49       ` Joonas Lahtinen

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=20190204090703.GI3271@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=airlied@redhat.com \
    --cc=carl.zhang@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=stephane.marchesin@gmail.com \
    --cc=timo.aaltonen@canonical.com \
    --cc=tiwai@suse.de \
    /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.