On Mon, 2016-08-15 at 15:34 +0300, Mika Kuoppala wrote: > 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. > I went back and forth; I think I did test on the BLT ring and maybe one of the video rings and things worked on at least one platform. But I'm still worried about bugs... Jesse _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
