Re: [PATCH] drm/i915: Flush the existing fence before GGTT read/write

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Chris Wilson (2019-08-23 16:31:19)
> Quoting Matthew Auld (2019-08-23 16:26:16)
> > On 23/08/2019 16:03, Chris Wilson wrote:
> > > Our fence management is lazy, very lazy. If the user marks an object as
> > > untiled, we do not immediately flush the fence but merely mark it as
> > > dirty. On the use we have to remember to check and remove the fence, by
> > > which time we hope it is idle and we do not have to wait.
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111468
> > > Fixes: 1f7fd484fff1 ("drm/i915: Replace i915_vma_put_fence()")
> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > > Cc: Matthew Auld <matthew.auld@xxxxxxxxx>
> > 
> > Well that sucks, should we also try to be more solid on the reloc path?
> 
> I was thinking about pulling it into the object_ggtt_pin. That appears
> to cover everyone.

An alternative would be not to be so lazy on changing tiling mode. We
are lazy because of the userspace caching, where it may inherit an
inappropriate tiling and so change it during object initialisation. That
used to introduce a stall, hence being lazy.

Although, the fence is on the vma. If we don't like the current fence,
we could just allocate a new vma. (If there isn't enough room for the
fresh vma, we would evict and hopefully stall on LRU one.) Hmm.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux