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 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 :\ Jason _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
