[Intel-gfx] [PATCH v6 00/19] 48-bit PPGTT

[Chris Wilson]

On Wed, Jul 29, 2015 at 05:23:44PM +0100, Michel Thierry wrote:
> This clean-up version delays the 48-bit work to later patches and includes
> more review comments from Akash and Chris. The first 5 patches prepare the
> dynamic page allocation code to handle independent pdps, but no specific
> code for 48-bit mode is added before the 5th patch.
> 
> In order expand the GPU address space, a 4th level translation is added,
> the Page Map Level 4 (PML4). This PML4 has 512 PML4 Entries (PML4E),
> PML4[0-511], each pointing to a PDP. All the existing "dynamic alloc
> ppgtt" functions are used, only adding the 4th level changes. I also
> updated some remaining variables that were 32b only.
> 
> There are 2 hardware workarounds needed to allow correct operation with
> 48b addresses (Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset).
> A flag (EXEC_OBJECT_SUPPORTS_48B_ADDRESS) will indicate if a given object can
> be allocated outside the first 4 PDPs; if not, the end range is forced to 4GB.
> Also, more objects now use the DRM_MM_CREATE_TOP flag. To maintain
> compatibility, in libdrm I added a new drm_intel_bo_emit_reloc_48bit function
> that will flag these objects, while the existing drm_intel_bo_emit_reloc
> clears it.
> 
> Finally, this feature is only available in BDW and Gen9, requires LRC
> submission mode (execlists) and it can be detected by i915.enable_ppgtt=3.
> 
> Also note that this expanded address space is only available for full
> PPGTT, aliasing PPGTT and Global GTT remain 32-bit.
> 
> I'll resend the userland patches (libdrm/mesa) in a different patchset, there
> haven't been changes on them, but they require a rebase. I will also expand the
> ppgtt igt test per Chris suggestions.

Just a head's up, I haven't root caused this yet, but with
i915.enable_ppgtt=2 I started getting GPU hangs that didn't happen
before this series...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre