Daniel Vetter <daniel@xxxxxxxx> writes: > On Tue, Feb 24, 2015 at 04:22:33PM +0000, Michel Thierry wrote: >> This patchset addresses comments from v5 by Mika, specially some rename changes >> touched several patches. >> >> For GEN8, it has also been extended to work in logical ring submission (lrc) >> mode, as it will be the preferred mode of operation. >> I also tried to update the lrc code at the same time the ppgtt refactoring >> occurred, leaving only one patch that is exclusively for lrc. >> >> I'm also now including the required patches for PPGTT with 48b addressing. >> In order expand the GPU address space, a 4th level translation is added, the >> Page Map Level 4 (PML4). This PML4 has 256 PML4 Entries (PML4E), PML4[0-255], >> each pointing to a PDP. >> >> For now, this feature will only be available in BDW and GEN9, in LRC submission >> mode (execlists) and when i915.enable_ppgtt=3 is set. >> Also note that this expanded address space is only available for full PPGTT, >> aliasing PPGTT remains 32b. >> >> This list can be seen in 3 parts: >> [01-10] Add page table allocation for GEN6/GEN7 >> [11-20] Enable dynamic allocation in GEN8,for both legacy and >> execlist submission modes. >> [21-32] PML4 support in BDW and GEN9+. >> >> Ben Widawsky (26): >> drm/i915: page table abstractions >> drm/i915: Complete page table structures >> drm/i915: Create page table allocators >> drm/i915: Track GEN6 page table usage >> drm/i915: Extract context switch skip and pd load logic >> drm/i915: Track page table reload need >> drm/i915: Initialize all contexts >> drm/i915: Finish gen6/7 dynamic page table allocation >> drm/i915/bdw: Use dynamic allocation idioms on free >> drm/i915/bdw: page directories rework allocation >> drm/i915/bdw: pagetable allocation rework >> drm/i915/bdw: Update pdp switch and point unused PDPs to scratch page >> drm/i915: num_pd_pages/num_pd_entries isn't useful >> drm/i915: Extract PPGTT param from page_directory alloc >> drm/i915/bdw: Split out mappings >> drm/i915/bdw: begin bitmap tracking >> drm/i915/bdw: Dynamic page table allocations >> drm/i915/bdw: Make pdp allocation more dynamic >> drm/i915/bdw: Abstract PDP usage >> drm/i915/bdw: Add dynamic page trace events >> drm/i915/bdw: Add ppgtt info for dynamic pages >> drm/i915/bdw: implement alloc/free for 4lvl >> drm/i915/bdw: Add 4 level switching infrastructure >> drm/i915/bdw: Generalize PTE writing for GEN8 PPGTT >> drm/i915: Plumb sg_iter through va allocation ->maps >> drm/i915: Expand error state's address width to 64b >> >> Michel Thierry (6): >> drm/i915: Plumb drm_device through page tables operations >> drm/i915: Add dynamic page trace events >> drm/i915/bdw: Support dynamic pdp updates in lrc mode >> drm/i915/bdw: Support 64 bit PPGTT in lrc mode >> drm/i915/bdw: Add 4 level support in insert_entries and clear_range >> drm/i915/bdw: Flip the 48b switch > > When just a few patches changed (which I suspect is the case here) please > don't resend the entire series, but only resend the individual patches > in-reply-to their earlier versions. > > Resending the entire series too often tends to split up the discussions > between multiple threads, so should be used cautiously. My approach is > that I don't resend the entire series except when all the patches have > changed. And I only resend when the review round has reached a conclusion. > While the review is ongoing doing incremental updates of the series is imo > much better. > > But when resending the entire series, please start a new thread. Otherwise > it again starts to become unclear which versions of which patches go > together. > > And a quick aside if you fear that a patch causes subsequent patches to no > longer apply without a rebase: I can deal with a lot of small conflicts > quickly when merging. And if that doesn't cut it I'll just ask for a > resend when needed. > I have been asking alot of stuff that triggers a rebasing. I suggest we should keep the 48b items in a separate series until we have most of the dynamic page table series sorted out. - Mika > Just a quick reminder of patch resending bkms, intel-gfx is a really busy > place so everyone needs to strive for best signal/noise ratio. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
