On Fri, Jul 10, 2020 at 4:23 PM Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote: > > On Fri, Jul 10, 2020 at 04:02:35PM +0200, Daniel Vetter wrote: > > > > dma_fence only possibly makes some sense if you intend to expose the > > > completion outside a single driver. > > > > > > The prefered kernel design pattern for this is to connect things with > > > a function callback. > > > > > > So the actual use case of dma_fence is quite narrow and tightly linked > > > to DRM. > > > > > > I don't think we should spread this beyond DRM, I can't see a reason. > > > > Yeah v4l has a legit reason to use dma_fence, android wants that > > there. > > 'legit' in the sense the v4l is supposed to trigger stuff in DRM when > V4L DMA completes? I would still see that as part of DRM Yes, and also the other way around. But thus far it didn't land. -Daniel > Or is it building a parallel DRM like DMA completion graph? > > > > Trying to improve performance of limited HW by using sketchy > > > techniques at the cost of general system stability should be a NAK. > > > > Well that's pretty much gpu drivers, all the horrors for a bit more speed :-) > > > > On the text itself, should I upgrade to "must not" instead of "should > > not"? Or more needed? > > Fundamentally having some unknowable graph of dependencies where parts > of the graph can be placed in critical regions like notifiers is a > complete maintenance nightmare. > > I think building systems like this should be discouraged :\ -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
