[PATCH libdrm v3 0/4] etna_pipe_wait_ns(..)

[Daniel Vetter]

On Wed, Nov 23, 2016 at 02:42:24PM -0500, Rob Clark wrote:
> On Wed, Nov 23, 2016 at 2:22 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> > On 23 November 2016 at 18:45, Rob Clark <robdclark at gmail.com> wrote:
> >> On Wed, Nov 23, 2016 at 1:18 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> >>> On 23 November 2016 at 07:26, Christian Gmeiner
> >>> <christian.gmeiner at gmail.com> wrote:
> >>>> Add an API to pass the timeout value (ns) from pipe->fence_finish(..)
> >>>> to the kernel. The current API accepts ms and special handling is needed
> >>>> for PIPE_TIMEOUT_INFINITE.
> >>>>
> >>>> The idea is not to break old mesa (out-of-tree) + new libdrm. It may be
> >>>> possible to break etnaviv's ABI as the gallium driver is not upstream yet
> >>>> but I am quite unsure whats the best solution.
> >>>>
> >>> I'm kind of split with a small inclination towards "break it" ;-)
> >>
> >> fwiw, I suggested the "don't break it" approach.. in the early days of
> >> a new FOSS gfx driver, it is hard enough for end users to pull
> >> together the right combination of trees to make things work, so lets
> >> not make it harder for them.  In the end, a FOSS driver is to enable
> >> the users ;-)
> >>
> > Which is kind of but not the same the thing I've mentioned - check if
> > driver devs/users have a preference and go ahead with it :-P
> > There is limited benefit in supporting "out of tree" code if most/all
> > the people don't care about it ... and Mesa is likely to land ~soonish
> >  ;-)
> 
> judging by activity on #etnaviv there are users..  (and ofc that is
> why I want to get mesa parts landed as-soonish-as-possible ;-))
> 
> I think in this particular case, there isn't really much downside for
> not breaking things for existing out-of-tree users.. we can always
> garbage-collect the old API that was never used upstream later.
> 
> > I see your point, hopefully mine was clear as well.
> 
> yeah, I think taking extraordinary measures for out of tree code is
> worth cost/benefit analysis.. in this case not breaking things isn't
> so painful and causes less headache as we get etnaviv merged
> upstream.. so seems like a win/win to me ;-)

Mesa should just finally get merged, and then it's not out-of-tree and
also clear that we should break abi. Christian promised this for last
week, didn't seem to have materialized yet. Why is this so hard?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch