[Intel-gfx] [PATCH 5/5] drm/i915: s/seqno/request/ tracking inside objects

[Chris Wilson]

On Tue, Sep 02, 2014 at 11:06:29AM +0100, John Harrison wrote:
> Hello,
> 
> Is this patch going to be split up into more manageable pieces? I
> tried to apply it to a tree fetched yesterday and got a very large
> number of conflicts. I don't know whether that is because more
> execlist patches have been merged or if it is other random changes
> that have broken it or if I am just missing earlier patches in the
> set.
> 
> The patch has been sent with subjects of '[PATCH]', '[PATCH 5/5]'
> and '[PATCH 3/3]'. However, all three emails seem to be the same
> humongous single part patch and I can't find any 0/3, 4/5, etc.
> emails. Am I missing some prep work patches without which the final
> monster patch is never going to apply?

The earlier patches were already upstream, but then execlists caused
further conflicts.

There's a fairly mechanical and mundane API conversion spread over
i915_gem*.c which should be easy to skim over. The most subtle part is
defining the order in which engine, contexts and rings are created and
enabled. The patch splits out the setup and enabling so that rings can
be created as children of both engines and contects, and so that the
resume path is clearly defined and split out from the setup. Given the
new api, we can then de-duplicate all the execlist code spread across
i915_gem*.c, and part of that is moving more engine specific code out of
gem. Finally, requests work as fences.

The problem is that, as I see it, defining requests to be independent of
the submission mechanism requires changes in how the rings are accessed
right the way through to how the requests are used themselves, and for
the most part there is no intermediate step. But as usually happens I
cannot see the wood for the trees.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre