Re: [PATCH v6 00/32] PPGTT dynamic page allocations and 48b addressing

[Mika Kuoppala <mika.kuoppala@linux.intel.com>]

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