[Intel-gfx] [PATCH 00/34] PPGTT prep part 2 (and unmerged part 1)
Ben Widawsky
ben at bwidawsk.net
Tue Jun 4 23:49:01 CEST 2013
On Sat, May 25, 2013 at 12:26:34PM -0700, Ben Widawsky wrote:
> Hello.
>
> I'm continuing to develop full PPGTT support for the i915 driver. This
> series is a follow-up to the previously posted RFC [1]. This series
> contains reworked versions of the unmerged patches (fingers crossed that
> I didn't miss review comments). I've rebased this series to hell and
> back, so I'm sure there are some lingering errors due to that. I've found
> several, but my eyes are no longer capable of finding them. I've also added
> some last minute fixups, which I always promise myself I'll never do because
> they always have bugs.
>
> To reiterate the steps I am planning to take which I did this in the
> previous RFC [1], but it has changed a bit:
>
> 1. Make a link between contexts and PPGTT. Every context has it's own
> address space implemented.
> 2. Create the VMA/VM, plumb through the driver.
> 3. Create a context per fd. This involves abstracting the notion of
> context to not just mean a HW context, but also an address space.
> 4. Switch address spaces on context switch.
> 5. Develop interfaces.
>
> This patch series addresses steps 1 & 2. A lot of the future patches
> should have much less room for debate on what color to paint the
> bikeshed, so I feel this is a good point to submit for some review. I am
> currently developing 3 & 4. I have some half baked patches which aren't
> really ready, but do give me some notion that things will work. Note
> that The order of 3 and 4 really matter because if we start switching
> page tables for applications not using contexts, everything will blow up
> pretty badly.
>
> To not scare off potential reviewers, even though the series is as long
> as it is, many of the patches really could be squashed. To keep rebase +
> easier review, I've split things out to multiple steps.
>
> 1-5: Random fixes.
> 6-15: Equivalent to reworked version of the PPGTT prep part 1
> 6-9: Make PPGTT PDE allocation more generic
> 10-15: Tie contexts to PPGTT.
>
> 16-34: create the VM and VMAs.
> 16-20: Mostly cut and paste to set us up for future patches.
> 21-25: Set up the address space abstraction.
> 26-31: Reorganize code to prepare for VMAs
> 31-34: are logically one patch. I split them out for my own debug
> after the enormous patch didn't work. I'm fine with squashing
> them in to 1 after review, or leaving a large bisect warning
> (as I've done).
>
> I do have a work in progress branch on fd.o [2]. This may not reflect this
> series 1:1 as it will have rebases, plus some future patches as I feel they are
> ready. If someone wants a branch on fd.o for review, please let me know.
>
> References:
> [1] http://lists.freedesktop.org/archives/intel-gfx/2013-April/027144.html
> [2] http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=ppgtt-prep-2
I've forced pushed the following to my repo linked above:
Rebased on the latest -nightly as the time.
Added a patch to disable ppgtt when on gen6 + vtd. This would have broken in
the old series. The patch is a bit tricky in that it will make the code paths
identical for PPGTT and non-PPGTT on GEN6, however it won't write the PPGTT
enable bits when vt-d is enabled. This patch is untested...
Kill guard page first, then move PDEs to a BO. Originally the patches were
submitted in the reverse order. Since we already have the PDEs above the guard
page, the guard page is immediately killable.
Rename gtt_list to global_list. This just clears confusion, and has already
been merged by Daniel.
Pin and unpin pages at bind/unbind. This will help keep put_pages clean. This
too has already been merged by Daniel.
>
--
Ben Widawsky, Intel Open Source Technology Center
More information about the Intel-gfx
mailing list