On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2018-05-04 09:23:01) > > On Fri, May 04, 2018 at 10:17:22AM +0200, Daniel Vetter wrote: > > > On Fri, May 04, 2018 at 09:09:10AM +0100, Chris Wilson wrote: > > > > Quoting Daniel Vetter (2018-05-03 15:25:52) > > > > > Almost everyone uses dma_fence_default_wait. > > > > > > > > > > v2: Also remove the BUG_ON(!ops->wait) (Chris). > > > > > > > > I just don't get the rationale for implicit over explicit. > > > > > > Closer approximation of dwim semantics. There's been tons of patch series > > > all over drm and related places to get there, once we have a big pile of > > > implementations and know what the dwim semantics should be. Individually > > > they're all not much, in aggregate they substantially simplify simple > > > drivers. > > > > I also think clearer separation between optional optimization hooks and > > mandatory core parts is useful in itself. > > A new spelling of midlayer ;) I don't see the contradiction with a > driver saying use the default and simplicity. (I know which one the > compiler thinks is simpler ;) If the compiler overhead is real then I guess it would makes to be explicit. I don't expect that to be a problem though for a blocking function. I disagree on this being a midlayer - you can still overwrite everything you please to. What it does help is people doing less copypasting (and assorted bugs), at least in the grand scheme of things. And we do have a _lot_ more random small drivers than just a few years ago. Reducing the amount of explicit typing just to get default bahaviour has been an ongoing theme for a few years now, and your objection here is about the first that this is not a good idea. So I'm somewhat confused. It's ofc not all that useful when looking only through the i915 perspective, where we overwrite almost everything anyway. But the ecosystem is a bit bigger than just i915. -Daniel -- 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
