2016-11-24 8:53 GMT+01:00 Daniel Vetter <daniel@xxxxxxxx>: > 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@xxxxxxxxx> wrote: >> > On 23 November 2016 at 18:45, Rob Clark <robdclark@xxxxxxxxx> wrote: >> >> On Wed, Nov 23, 2016 at 1:18 PM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: >> >>> On 23 November 2016 at 07:26, Christian Gmeiner >> >>> <christian.gmeiner@xxxxxxxxx> 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? This was the last issue (in my eyes I want to get right). The patches are prepared so yes.. it should finally happen. Greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
