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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
