On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter <daniel@xxxxxxxx> wrote: > > 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. FWIW I think the API changes are fine. Sure it feels a bit odd at first, but there's no better alternative that I can see either. Acked-by: Stéphane Marchesin <marcheu@xxxxxxxxxxxx> > -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@xxxxxxxxxxxxxxxxxxxxx > > > Cc: Timo Aaltonen <timo.aaltonen@xxxxxxxxxxxxx> > > > Cc: Takashi Iwai <tiwai@xxxxxxx> > > > Cc: Stephane Marchesin <stephane.marchesin@xxxxxxxxx> > > > Cc: Dave Airlie <airlied@xxxxxxxxxx> > > > Cc: Daniel Vetter <daniel@xxxxxxxx> > > > > > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
