On Wed, Apr 13, 2016 at 10:14:50AM +0100, Tvrtko Ursulin wrote: > On 13/04/16 10:04, Chris Wilson wrote: > >On Wed, Apr 13, 2016 at 09:45:03AM +0100, Tvrtko Ursulin wrote: > >>I could have two separate series to simplify dependencies a bit: > >> > >> 1. GuC premature unpin and > >> 2. execlist no retired queue. > >> > >>The stack for the first one could look like (not as patches but > >>conceptually): > >> > >> 1. default context cleanup > >> 2. any io_mapping patches of yours > >> 3. i915_vma_iomap or WC pin_map as you suggested in the other reply. > >> 4. previous / pinned context > >> > >>Execlist no retired queue would then be: > >> > >> 1. stable ctx id > >> 2. removal of i915_gem_request_unreference__unlocked > >> 3. execlist no retired queue > >> > >>If I did not forget about something. > >> > >>At any point in any series we could add things like > >>i915_gem_request.c or those patches which move around the context > >>init. > > > >Could I see you some drm_mm.c patches after that? > > If I am competent enough to help with them sure. There's a nice tweak in there to help with the aperture thrashing scenario (speeds up the aperture thrash tests in gem_concurrent_blit by ~60x). You mentioned you were interested in similar scenarios. Besides which they actually fix the u64 alignment issues and some residual u32 problems. > Does this mean above sounds like a plan to you? Two series > containing the listed items? 3. I'll get io_mapping changes ratified, and that can happen in parallel to these two series. -Chris > -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx