Re: [PATCH 2/5] drm/i915: Fallback to using CPU relocations for large batch buffers

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

 



On Wed, Jan 28, 2015 at 10:14:47AM +0100, Daniel Vetter wrote:
> On Tue, Jan 27, 2015 at 09:43:00PM +0000, Chris Wilson wrote:
> > On Tue, Jan 27, 2015 at 04:09:37PM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 14, 2015 at 11:20:56AM +0000, Chris Wilson wrote:
> > > >  static int
> > > >  i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> > > >  				struct intel_engine_cs *ring,
> > > > @@ -536,14 +589,21 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> > > >  	int ret;
> > > >  
> > > >  	flags = 0;
> > > > -	if (entry->flags & __EXEC_OBJECT_NEEDS_MAP)
> > > > -		flags |= PIN_GLOBAL | PIN_MAPPABLE;
> > > > -	if (entry->flags & EXEC_OBJECT_NEEDS_GTT)
> > > > -		flags |= PIN_GLOBAL;
> > > > -	if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS)
> > > > -		flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
> > > > +	if (!drm_mm_node_allocated(&vma->node)) {
> > > > +		if (entry->flags & __EXEC_OBJECT_NEEDS_MAP)
> > > > +			flags |= PIN_GLOBAL | PIN_MAPPABLE;
> > > > +		if (entry->flags & EXEC_OBJECT_NEEDS_GTT)
> > > > +			flags |= PIN_GLOBAL;
> > > > +		if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS)
> > > > +			flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
> > > > +	}
> > > 
> > > Hm, aren't we always calling reserve un buffers we know we've just
> > > unbound? Keeping the flags computation would at least be a good selfcheck
> > > about the consistency of our placing decisions, so I'd like to keep it.
> 
> I still think this isn't required, even with the ping-pong preventer below
> kept. Maybe add a WARN_ON(drm_mm_node_allocated); just for paranoia
> instead?

The issue I have with this chunk here is that we have two not quite
duplicate pieces of code deciding when to migrate an object:
i915_vma_misplaced() vs eb_vma_misplaced().

Maybe a __i915_vma_pin(), but as it stands atm
i915_gem_object_pin_view() requires some TLC first.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://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