Re: [PATCH v5] igt/gem_trtt: Exercise the TRTT hardware

[Michel Thierry <michel.thierry@intel.com>]

On 3/11/2016 11:48 AM, akash.goel@intel.com wrote:
> From: Akash Goel <akash.goel@intel.com>
>
> This patch provides the testcase to exercise the TRTT hardware.
>
> Some platforms have an additional address translation hardware support in
> form of Tiled Resource Translation Table (TR-TT) which provides an extra level
> of abstraction over PPGTT.
> This is useful for mapping Sparse/Tiled texture resources.
>
> TR-TT is tightly coupled with PPGTT, a new instance of TR-TT will be required
> for a new PPGTT instance, but TR-TT may not enabled for every context.
> 1/16th of the 48bit PPGTT space is earmarked for the translation by TR-TT,
> which such chunk to use is conveyed to HW through a register.
> Any GFX address, which lies in that reserved 44 bit range will be translated
> through TR-TT first and then through PPGTT to get the actual physical address.
>
> TRTT is constructed as a 3 level tile Table. Each tile is 64KB is size which
> leaves behind 44-16=28 address bits. 28bits are partitioned as 9+9+10, and
> each level is contained within a 4KB page hence L3 and L2 is composed of
> 512 64b entries and L1 is composed of 1024 32b entries.
>
> There is a provision to keep TR-TT Tables in virtual space, where the pages of
> TRTT tables will be mapped to PPGTT. This is the adopted mode, as in this mode
> UMD will have a full control on TR-TT management, with bare minimum support
> from KMD.
> So the entries of L3 table will contain the PPGTT offset of L2 Table pages,
> similarly entries of L2 table will contain the PPGTT offset of L1 Table pages.
> The entries of L1 table will contain the PPGTT offset of BOs actually backing
> the Sparse resources.
>
> I915_GEM_CONTEXT_SETPARAM ioctl is used to request KMD to enable TRTT for a
> certain context, a new I915_CONTEXT_PARAM_ENABLE_TRTT param has been
> added to the CONTEXT_SETPARAM ioctl for that purpose.
>
> v2:
>   - Add new wrapper function __gem_context_require_param and used that
>     to detect the TR-TT support
>   - Use igt_main macro, rename certain function, remove extra white space,
>     cleanup the code (Chris)
>   - Enhance the basic subtest to exercise all possible TR-TT segment start
>     locations (i.e. 16 of them) & for every iteration create a new context.
>
> v3:
>   - Get rid of some superfluous local variables (Chris)
>   - Add asserts to validate whether the GFX address used in MI_STORE_DATA_IMM
>     command is in canonical form & is correctly aligned or not (Chris)
>   - Remove clearing of errno in has_trtt_support function (Chris)
>   - Use the 48B_ADDRESS flag for batch buffer BO also (Chris)
>   - Rebased.
>
> v4:
>   - Add new subtest for invalid settings.
>   - Add new local function query_trtt to check the Driver state (Chris)
>   - Add new helper function gem_uses_64b_ppgtt to detect 64bit PPGTT support
>   - Remove local functions uses_full_ppgtt & has_softpin_support, instead use
>     existing wrappers gem_has_softpin & gem_uses_64b_ppgtt (Chris).
>   - Remove redundant bit masking in emit_store_xxx functions (Chris).
>
> v5:
>   - Add 2 new subtests checking the forceful eviction of active/hanging
>     objects overlapping with the TR-TT segment (Chris).
>   - Move gen8_canonical_addr to igt_aux as its needed by other tests also,
>     which does soft pinning, and not just gem_softpin (Michel)
>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Michel Thierry <michel.thierry@intel.com>
> Signed-off-by: Akash Goel <akash.goel@intel.com>

Test looks good to me.

Reviewed-by: Michel Thierry <michel.thierry@intel.com>


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx