On Wed, Nov 05, 2014 at 10:50:24AM +0100, Daniel Vetter wrote:
> On Tue, Nov 04, 2014 at 08:35:00AM -0800, Volkin, Bradley D wrote:
> > On Tue, Nov 04, 2014 at 02:17:59AM -0800, Daniel Vetter wrote:
> > > On Mon, Nov 03, 2014 at 11:19:42AM -0800, bradley.d.volkin@xxxxxxxxx wrote:
> > > > + if (!ret) {
> > > > + ret = i915_gem_object_set_to_gtt_domain(shadow_batch_obj,
> > > > + false);
> > >
> > > This smells like hacking around the domain tracking system. The batch is
> > > executed by the gpu, gtt domain is for cpu access. This might also be a
> > > reason why the shrinker wreaks havoc with you shadow patches. With the
> > > correct pending_read_domains move_to_active should take care of things
> > > mostly.
> >
> > Ok, I'll look at this again. I was using the golden context batch buffer code
> > as a reference for this, so perhaps there's something to fix there as well.
>
> Hm, indeed that's a bit hacked up too. So let's document the sequenc as
> it's used by execbuf:
>
> i915_gem_execbuffer_move_to_gpu takes care of any cpu and gpu side cache
> flushing. For the cmd parser you should be able to reuse that just by
> putting the the shadow batch vma onto the execbuf list. render ctx init
> would need to send in a single entry vma list.
>
> i915_gem_execbuffer_move_to_active updates the domain tracking an puts the
> vma onto the active list. That requires correctly adjusted
> pending_read_domains though.
>
> With these two no set_to_gtt domain should be required for flushing data
> out. Mika, can you perhaps look into this, together with kerneldoc for the
> render init functions?
Actually cc Mika ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
