On Mon, Apr 13, 2015 at 03:48:51PM -0400, Jerome Glisse wrote: > On Mon, Apr 13, 2015 at 08:26:05PM +0200, Christian König wrote: > > On 13.04.2015 19:51, Jerome Glisse wrote: > > >On Mon, Apr 13, 2015 at 07:23:34PM +0200, Daniel Vetter wrote: > > >>On Mon, Apr 13, 2015 at 04:52:17PM +0200, Christian König wrote: > > >>>From: Christian König <christian.koenig@xxxxxxx> > > >>> > > >>>WIP patch which adds an user fence IOCTL. > > >>> > > >>>Signed-off-by: Christian König <christian.koenig@xxxxxxx> > > >>I've discussed userspace fences a lot with Jerome last XDC, so here's my > > >>comments: > > >> > > >>My primary concern with mid-batch fences is that if we create real kernel > > >>fences (which might even escape to other places using android syncpts or > > >>dma-buf) then we end up relying upon correct userspace to not hang the > > >>kernel, which isn't good. > > >Yes i agree on that, solution i propose make sure that this can not happen. > > > > What if we want to base a GPU scheduler and Android sync points on that > > functionality? E.g. it might be necessary to create "struct fence" objects > > which are based on the information from userspace. > > > > Would that be possible or would we run into issues? > > Well i would not like that, but i do not like Android code much, but you > could use the same code as i show in my other email and just have the > android fence struct take a reference on the BO where the fence is. Then > using same code to check status. > > Obviously there should be timeout as there is no way for the kernel to > know if such fence will ever signal. Yeah I think if your umd is using this for all fencing needs, including cross-process and everything then I don't think it's such a good idea any more ;-) But if it's just fine-grained sync for heterogenous compute within the same process (ocl, hsa or whatever) then this seems reasonable. I guess this boils down to what the userspace side will look like, and what kind of standard you're trying to implement here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
