Re: [Intel-gfx] [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
Quoting Stéphane Marchesin (2019-02-05 06:16:48) > On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter 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 > Dave commented on IRC that he's fine with us proceeding to merge with these Acks in place. Thank you all for looking into the matter, this will now find its way into Kernel version 5.1. Regards, Joonas > > > -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 ( > > > 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-de...@lists.freedesktop.org > > > > Cc: Timo Aaltonen > > > > Cc: Takashi Iwai > > > > Cc: Stephane Marchesin > > > > Cc: Dave Airlie > > > > Cc: Daniel Vetter > > > > > > > > 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] > > > >
Re: [Intel-gfx] [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter 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 > -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 ( > > 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-de...@lists.freedesktop.org > > > Cc: Timo Aaltonen > > > Cc: Takashi Iwai > > > Cc: Stephane Marchesin > > > Cc: Dave Airlie > > > Cc: Daniel Vetter > > > > > > 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
Re: [Intel-gfx] [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
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 ( > 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-de...@lists.freedesktop.org > > Cc: Timo Aaltonen > > Cc: Takashi Iwai > > Cc: Stephane Marchesin > > Cc: Dave Airlie > > Cc: Daniel Vetter > > > > 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 + > >
Re: [Intel-gfx] [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
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. 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 ( 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-de...@lists.freedesktop.org > Cc: Timo Aaltonen > Cc: Takashi Iwai > Cc: Stephane Marchesin > Cc: Dave Airlie > Cc: Daniel Vetter > > 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 >
[Intel-gfx] [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
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] 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 (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-de...@lists.freedesktop.org Cc: Timo Aaltonen Cc: Takashi Iwai Cc: Stephane Marchesin Cc: Dave Airlie Cc: Daniel Vetter 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
