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

Rob Clark robdclark at gmail.com
Wed Nov 23 19:42:24 UTC 2016


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 ;-)

BR,
-R

> Emil


More information about the dri-devel mailing list