[Intel-xe] [RFC PATCH 0/3] Xe dma fence handling on atomic commit

Hogander, Jouni jouni.hogander at intel.com
Thu Sep 28 08:23:41 UTC 2023


On Wed, 2023-09-27 at 14:35 +0200, Maarten Lankhorst wrote:
> Hey,
> 
> On 2023-09-27 12:45, Hogander, Jouni wrote:
> > 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.
> In atomic, plane_state->fence is set for all fences, and that should
> be 
> enough. I think creating a reservation object is a massive overkill,
> and we should try to use the drm_atomic_helper_wait_for_fences if at
> all 
> possible.

Checked this plane_state->fence. To me it looks like it's for userspace
to set? I don't think this is the case for i915. For Xe, I don't know
is it done?

Also i915 is waiting for fences on old frame buffer objects and new fb
objects. Shouldn't we do the same for Xe as well? Anyways there is
currently no mechanism in dma_fence implementation to have common fence
for two separate dma_resv objects (dma_resv_get_singleton) -> I did
this by creating a new dma_resv for this purpose. If there is no reason
to wait for possible fences on old fb object, maybe we could just do
dma_resv_get_singleton in prepare planes for Xe and wait for that and
uapi.fence in commit?

BR,

Jouni Högander
> 
> Cheers,
> ~Maarten



More information about the Intel-xe mailing list