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 ;-) BR, -R > Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
