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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to