On 2/25/2015 10:55 AM, Mika Kuoppala wrote:
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 switchWhen 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
Ok, I'll keep dynamic page allocation and 48b separated. -Michel
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
