On Fri, Jul 13, 2012 at 09:53:33AM +0100, Chris Wilson wrote:
> On Fri, 13 Jul 2012 09:49:48 +0100, Chris Wilson
> wrote:
> > No. Because by the time the previous breadcrumb has been seen we are
> > guarranteed to have flushed the gpu caches. So any wait in the future we
> > have flushed the cach
On Fri, 13 Jul 2012 09:49:48 +0100, Chris Wilson
wrote:
> No. Because by the time the previous breadcrumb has been seen we are
> guarranteed to have flushed the gpu caches. So any wait in the future we
> have flushed the caches before returning.
Egg on face time.
The issue is on the waiter side
On Fri, 13 Jul 2012 10:34:43 +0200, Daniel Vetter wrote:
> On Thu, Jul 12, 2012 at 09:07:52PM +0100, Chris Wilson wrote:
> > On Thu, 12 Jul 2012 21:37:16 +0200, Daniel Vetter wrote:
> > > On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote:
> > > > obj->base.write_domain
On Thu, Jul 12, 2012 at 09:07:52PM +0100, Chris Wilson wrote:
> On Thu, 12 Jul 2012 21:37:16 +0200, Daniel Vetter wrote:
> > On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote:
> > > obj->base.write_domain = 0;
> > > - list_del_init(&obj->gpu_write_list);
> > > +
On Thu, 12 Jul 2012 21:37:16 +0200, Daniel Vetter wrote:
> On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote:
> > obj->base.write_domain = 0;
> > - list_del_init(&obj->gpu_write_list);
> > + obj->pending_gpu_write = false;
> > i915_gem_object_
On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote:
> This is now handled by a global flag to ensure we emit a flush before
> the next serialisation point (if we failed to queue one previously).
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h|2 -
This is now handled by a global flag to ensure we emit a flush before
the next serialisation point (if we failed to queue one previously).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|2 -
drivers/gpu/drm/i915/i915_gem.c| 55 ++
