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

Michel Thierry michel.thierry at intel.com
Thu Jul 30 04:52:19 PDT 2015


On 7/30/2015 12:26 PM, Chris Wilson wrote:
> 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
>

Sounds like I screwed up something in the first 4 patches or in the 
Wa32bit one. The rest of the changes are contained to 48-bit code.

Have you find a way to reproduce it?

Thanks,

-Michel


More information about the Intel-gfx mailing list