Re: [PATCH 2/2] drm/i915: Move the policy for placement of the GGTT vma into the caller

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

 



Quoting Ville Syrjälä (2018-02-20 11:39:13)
> On Tue, Feb 20, 2018 at 10:50:11AM +0000, Chris Wilson wrote:
> > @@ -490,6 +491,8 @@ struct intel_atomic_state {
> >  struct intel_plane_state {
> >       struct drm_plane_state base;
> >       struct i915_vma *vma;
> > +     unsigned long flags;
> 
> long seems potentially wasteful when we have just the one flag.
> Although maybe the next thing gets aligned to 64bits anyway.

Yeah, wasteful until you look at the holes. :) I tend to find I run out
of flag space all too quick so erred on the side of plenty of bits. Plus
it stops all the arguments about BIT() being UL but the type just U.

> Anyways, patch looks reasonable.
> Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> 
> fbc should probably start looking at the new flag instead of
> using the racy vma->fence checks it has now.

Right, I was looking at how we could pass requirements like we want fbc
so try harder to give us a fence (with the usual cop-out of if we are
triple buffering 4k screens, we run out of mappable very quickly).
Hooking up to the plane->flags & HAS_FENCE is a good idea.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux