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

[Christian Gmeiner]

2016-11-24 8:53 GMT+01:00 Daniel Vetter <daniel at ffwll.ch>:
> 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?

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