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
