Fence, timeline and android sync points

[Daniel Vetter]

On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> Yes preemption and gpu scheduling would break such scheme, but my point is
> that when you have such gpu you want to implement a proper solution. Which
> of course require quite some work accross the stack. So the past can live
> on but the future needs to get its acts together.
>
>> The other problem is that the Linux Desktop I don't seem to care about
>> any more kinda relies on implicit syncing right now, so we better keep
>> that working fairly well. Of course we could dream up a shiny new
>> world where all of the Linux desktop does explicit syncing, but that
>> world doesn't exist right now. I mean really if you want to right away
>> throw implicit syncing overboard that doesn't bode well for the
>> current linux desktop.
>
> Again i fail at expressing myself. I am saying throw things over board,
> i am well aware of the current reliance on implicit fencing. I am saying
> if fence wants to be this new thing that should allow to do explicit
> fencing in the future than it better be done correctly in the first place.
>
>> So I don't understand all the implicit syncing bashing. It's here, and
>> it'll stay for a while longer whether you like it or not ...
>
> I am saying this is where we are and it sucks for a number of reasons,
> then looking at fence and by looking at fence i am saying this try to
> go in the right direction but do crazy things that i am convince we
> will regret. In other word if we ever get to the explicit fence better
> starts on the right path with the right tool. Moreover i am saying that
> this can be done without breaking implicit sync we have today.
>
>> Of course that doesn't mean we (intel here) won't support explicit
>> syncing too, and I really don't see a conflict here when mixing and
>> matching these two approaches.
>
> Again i fail to express myself. I am not saying there is conflict. I
> am saying better take a path which allow to go full way with explicit
> fencing while still allowing a less optimal use for an implicit sync
> model.
>
> My point is the fence code proposed here, keeps the worst thing about
> implicit fencing we have today. This can be done differently, in what
> i believe to be better way. And this different approach stills allow
> to have have implicit sync for existing userspace.

Well the problem is I can't wait for that shiny new world to finally
arrive, I kinda have to work with what's there. Which is ugly, messy,
but that's how it is.

So I'm not going to throw away piles of code just because it's ugly
and combining it with the new world is a major pain. Instead I'll
gobble down the ugly, throw testcases at the problem to make sure it
works and ship this frankenstein monster.

If you actually look at development stats we've completely rewritten
i915.ko in the past 2 years (again) and will likely continue for a
while. But we do that with small (tiny) steps and not with big jumps,
because with the current pace and ongoing projects that's plainly too
disruptive. So I envy you if you can do this with radeon, but there's
no way I can do that with i915, I just have to live with it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch