From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"maarten.lankhorst@linux.intel.com"
<maarten.lankhorst@linux.intel.com>
Cc: "Nikula, Jani" <jani.nikula@intel.com>
Subject: Re: [Intel-xe] [RFC PATCH 0/3] Xe dma fence handling on atomic commit
Date: Wed, 27 Sep 2023 10:45:28 +0000 [thread overview]
Message-ID: <2fd37d47aacb192f9d4b4e8491743323536f364c.camel@intel.com> (raw)
In-Reply-To: <ee8b5153-1cbd-4ab3-2b1a-626b13fbd761@linux.intel.com>
On Wed, 2023-09-27 at 12:33 +0200, Maarten Lankhorst wrote:
> Hey,
>
> When we wrote the original display support, we purposely decided on
> not
> adding i915_sw_fence support.
>
> In this case, I think a better approach would be to remove this code
> from i915 as well, and end up with cleaner display code for both
> drivers.
Yes, I agree eventually this would be the goal. I did some experiments
here:
https://patchwork.freedesktop.org/patch/558982/?series=123898&rev=4
Which is replacing i915_sw_fence with same code I'm using for Xe driver
in this patch set. The problem is GPU reset detection. I don't have
currently good ideas how to tackle that without compromizing i915
functionality in this scenario -> ended up doing this only for Xe to
ensure this is not blocking upstreaming Xe. Would this be acceptable as
temporary solution to be solved after upstreaming? Anyways what I'm
doing in these patches is not really an i915_sw_fence revised, but
using dma_fences.
BR,
Jouni Högander
> Cheers,
> ~Maarten
>
> On 2023-09-27 09:31, Jouni Högander wrote:
> > This patch set is reverting current changes to fence handling
> > during
> > atomic commit. A new compatibility header addressing lack of
> > i915_sw_fence implementation in Xe is introduced. This header
> > contains
> > dma fence handling during atomic commit for Xe driver and
> > interfaces
> > are following current i915_sw_fence implementation.
> >
> > Additionally change to current atomic commit code and i915_sw_fence
> > is
> > needed. This patch has to go to i915 upstream. It is needed due to
> > missing GT reset status in Xe driver. In case of i915 this status
> > is
> > polled while waiting for dma fences and in case of GT reset atomic
> > commit is completed even if dma fences are not signalled. I'm not
> > sure
> > how GT reset is supposed to be handled in case of Xe? Maybe dma
> > fences
> > are signaled if GT reset occures?
> >
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> >
> > Jouni Högander (3):
> > Revert "FIXME: drm/i915: fence stuff"
> > drm/i915/display: Move fence completion wait away from display
> > code
> > fixup! drm/xe/display: Implement display support
> >
> > drivers/gpu/drm/i915/display/intel_atomic.c | 2 -
> > drivers/gpu/drm/i915/display/intel_display.c | 50 +-------
> > .../drm/i915/display/intel_display_types.h | 3 +-
> > drivers/gpu/drm/i915/i915_sw_fence.c | 28 +++++
> > drivers/gpu/drm/i915/i915_sw_fence.h | 4 +
> > .../gpu/drm/xe/compat-i915-headers/i915_drv.h | 1 -
> > .../xe/compat-i915-headers/i915_sw_fence.h | 111
> > ++++++++++++++++++
> > 7 files changed, 145 insertions(+), 54 deletions(-)
> > create mode 100644 drivers/gpu/drm/xe/compat-i915-
> > headers/i915_sw_fence.h
> >
next prev parent reply other threads:[~2023-09-27 10:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 7:31 [Intel-xe] [RFC PATCH 0/3] Xe dma fence handling on atomic commit Jouni Högander
2023-09-27 7:31 ` [Intel-xe] [RFC PATCH 1/3] Revert "FIXME: drm/i915: fence stuff" Jouni Högander
2023-09-27 7:31 ` [Intel-xe] [RFC PATCH 2/3] drm/i915/display: Move fence completion wait away from display code Jouni Högander
2023-09-27 7:31 ` [Intel-xe] [RFC PATCH 3/3] fixup! drm/xe/display: Implement display support Jouni Högander
2023-09-27 7:34 ` [Intel-xe] ✓ CI.Patch_applied: success for Xe dma fence handling on atomic commit Patchwork
2023-09-27 7:34 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-09-27 7:35 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-09-27 7:42 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-09-27 7:43 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-09-27 7:44 ` [Intel-xe] ✗ CI.checksparse: warning " Patchwork
2023-09-27 8:16 ` [Intel-xe] ✓ CI.BAT: success " Patchwork
2023-09-27 10:33 ` [Intel-xe] [RFC PATCH 0/3] " Maarten Lankhorst
2023-09-27 10:45 ` Hogander, Jouni [this message]
2023-09-27 12:35 ` Maarten Lankhorst
2023-09-28 8:23 ` Hogander, Jouni
2023-09-28 16:10 ` Ville Syrjälä
2023-09-28 16:21 ` Ville Syrjälä
2023-10-16 11:22 ` Hogander, Jouni
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=2fd37d47aacb192f9d4b4e8491743323536f364c.camel@intel.com \
--to=jouni.hogander@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=maarten.lankhorst@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox