On Wed, Jul 17, 2013 at 03:44:16PM +0100, Chris Wilson wrote:
> On Wed, Jul 17, 2013 at 02:51:28PM +0200, Daniel Vetter wrote:
> > To avoid stalls we delay tiling changes and especially hold of
> > committing the new fence state for as long as possible.
> > Synchronization points are in the execbuf
On Wed, Jul 17, 2013 at 08:34:48AM -0700, Jesse Barnes wrote:
> On Wed, 17 Jul 2013 14:51:28 +0200
> Daniel Vetter wrote:
>
> > + if (reg->obj) {
> > + i915_gem_object_update_fence(reg->obj, reg,
> > +reg->obj->tiling_mod
On Wed, 17 Jul 2013 14:51:28 +0200
Daniel Vetter wrote:
> + if (reg->obj) {
> + i915_gem_object_update_fence(reg->obj, reg,
> + reg->obj->tiling_mode);
> + } else {
> + i915_gem_write_
On Wed, Jul 17, 2013 at 02:51:28PM +0200, Daniel Vetter wrote:
> To avoid stalls we delay tiling changes and especially hold of
> committing the new fence state for as long as possible.
> Synchronization points are in the execbuf code and in our gtt fault
> handler.
>
> Unfortunately we've missed
To avoid stalls we delay tiling changes and especially hold of
committing the new fence state for as long as possible.
Synchronization points are in the execbuf code and in our gtt fault
handler.
Unfortunately we've missed that tricky detail when adding proper fence
restore code in
commit 19b2dbd
