Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > On Mon, Aug 15, 2016 at 02:48:06PM +0300, Mika Kuoppala wrote: >> From: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> >> >> We just need to pass in an address to execute and some flags, since we >> don't have to worry about buffer relocation or any of the other usual >> stuff. Returns a fence to be used for synchronization. >> >> v2: add a request after batch submission (Jesse) >> v3: add a flag for fence creation (Chris) >> v4: add CLOEXEC flag (Kristian) >> add non-RCS ring support (Jesse) >> v5: update for request alloc change (Jesse) >> v6: new sync file interface, error paths, request breadcrumbs >> v7: always CLOEXEC for sync_file_install >> v8: rebase on new sync file api >> v9: rework on top of fence requests and sync_file >> v10: take fence ref for sync_file (Chris) >> use correct flush (Chris) >> limit exec on rcs > > This is incomplete, so just proof of principle? At some point of rebasing I noticed that Jesse did limit everything on rcs. So I just put it back. No idea yet why we would need to limit for rcs only. -Mika > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
