From: Ramalingam C <ramalingam.c@intel.com> To: intel-gfx <intel-gfx@lists.freedesktop.org>, dri-devel <dri-devel@lists.freedesktop.org> Cc: Hellstrom Thomas <thomas.hellstrom@intel.com>, Matthew Auld <matthew.auld@intel.com> Subject: [PATCH v2 0/4] drm/i915/ttm: Evict and store of compressed object Date: Wed, 2 Mar 2022 03:23:30 +0530 [thread overview] Message-ID: <20220301215334.20543-1-ramalingam.c@intel.com> (raw) On Xe-HP and later devices, we use dedicated compression control state (CCS) stored in local memory for each surface, to support the 3D and media compression formats. The memory required for the CCS of the entire local memory is 1/256 of the local memory size. So before the kernel boot, the required memory is reserved for the CCS data and a secure register will be programmed with the CCS base address So when we allocate a object in local memory we dont need to explicitly allocate the space for ccs data. But when we evict the obj into the smem to hold the compression related data along with the obj we need smem space of obj_size + (obj_size/256). Hence when we create smem for an obj with lmem placement possibility we create with the extra space. When we are swapping out the local memory obj on flat-ccs capable platform, we need to capture the ccs data too along with main meory and we need to restore it when we are swapping in the content. When lmem object is swapped into a smem obj, smem obj will have the extra pages required to hold the ccs data corresponding to the lmem main memory. So main memory of lmem will be copied into the initial pages of the smem and then ccs data corresponding to the main memory will be copied to the subsequent pages of smem. Swapin happens exactly in reverse order. First main memory of lmem is restored from the smem's initial pages and the ccs data will be restored from the subsequent pages of smem. Extracting and restoring the CCS data is done through a special cmd called XY_CTRL_SURF_COPY_BLT Test-with: 20220301212513.30772-1-ramalingam.c@intel.com Ayaz A Siddiqui (1): drm/i915/gt: Clear compress metadata for Xe_HP platforms Ramalingam C (3): drm/ttm: parameter to add extra pages into ttm_tt drm/i915/gem: Extra pages in ttm_tt for ccs data drm/i915/migrate: Evict and restore the flatccs capable lmem obj drivers/gpu/drm/drm_gem_vram_helper.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 23 +- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 15 + drivers/gpu/drm/i915/gt/intel_migrate.c | 327 +++++++++++++++++-- drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +- drivers/gpu/drm/ttm/ttm_tt.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +- include/drm/ttm/ttm_tt.h | 4 +- 9 files changed, 357 insertions(+), 32 deletions(-) -- 2.20.1
WARNING: multiple messages have this Message-ID (diff)
From: Ramalingam C <ramalingam.c@intel.com> To: intel-gfx <intel-gfx@lists.freedesktop.org>, dri-devel <dri-devel@lists.freedesktop.org> Cc: Hellstrom Thomas <thomas.hellstrom@intel.com>, Matthew Auld <matthew.auld@intel.com> Subject: [Intel-gfx] [PATCH v2 0/4] drm/i915/ttm: Evict and store of compressed object Date: Wed, 2 Mar 2022 03:23:30 +0530 [thread overview] Message-ID: <20220301215334.20543-1-ramalingam.c@intel.com> (raw) On Xe-HP and later devices, we use dedicated compression control state (CCS) stored in local memory for each surface, to support the 3D and media compression formats. The memory required for the CCS of the entire local memory is 1/256 of the local memory size. So before the kernel boot, the required memory is reserved for the CCS data and a secure register will be programmed with the CCS base address So when we allocate a object in local memory we dont need to explicitly allocate the space for ccs data. But when we evict the obj into the smem to hold the compression related data along with the obj we need smem space of obj_size + (obj_size/256). Hence when we create smem for an obj with lmem placement possibility we create with the extra space. When we are swapping out the local memory obj on flat-ccs capable platform, we need to capture the ccs data too along with main meory and we need to restore it when we are swapping in the content. When lmem object is swapped into a smem obj, smem obj will have the extra pages required to hold the ccs data corresponding to the lmem main memory. So main memory of lmem will be copied into the initial pages of the smem and then ccs data corresponding to the main memory will be copied to the subsequent pages of smem. Swapin happens exactly in reverse order. First main memory of lmem is restored from the smem's initial pages and the ccs data will be restored from the subsequent pages of smem. Extracting and restoring the CCS data is done through a special cmd called XY_CTRL_SURF_COPY_BLT Test-with: 20220301212513.30772-1-ramalingam.c@intel.com Ayaz A Siddiqui (1): drm/i915/gt: Clear compress metadata for Xe_HP platforms Ramalingam C (3): drm/ttm: parameter to add extra pages into ttm_tt drm/i915/gem: Extra pages in ttm_tt for ccs data drm/i915/migrate: Evict and restore the flatccs capable lmem obj drivers/gpu/drm/drm_gem_vram_helper.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 23 +- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 15 + drivers/gpu/drm/i915/gt/intel_migrate.c | 327 +++++++++++++++++-- drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +- drivers/gpu/drm/ttm/ttm_tt.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +- include/drm/ttm/ttm_tt.h | 4 +- 9 files changed, 357 insertions(+), 32 deletions(-) -- 2.20.1
next reply other threads:[~2022-03-01 21:53 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-01 21:53 Ramalingam C [this message] 2022-03-01 21:53 ` [Intel-gfx] [PATCH v2 0/4] drm/i915/ttm: Evict and store of compressed object Ramalingam C 2022-03-01 21:53 ` [PATCH v2 1/4] drm/i915/gt: Clear compress metadata for Xe_HP platforms Ramalingam C 2022-03-01 21:53 ` [Intel-gfx] " Ramalingam C 2022-03-03 7:39 ` Hellstrom, Thomas 2022-03-03 7:39 ` [Intel-gfx] " Hellstrom, Thomas 2022-03-01 21:53 ` [PATCH v2 2/4] drm/ttm: parameter to add extra pages into ttm_tt Ramalingam C 2022-03-01 21:53 ` [Intel-gfx] " Ramalingam C 2022-03-02 12:54 ` Thomas Hellström 2022-03-02 12:54 ` [Intel-gfx] " Thomas Hellström 2022-03-02 13:24 ` Christian König 2022-03-02 13:24 ` [Intel-gfx] " Christian König 2022-03-01 21:53 ` [PATCH v2 3/4] drm/i915/gem: Extra pages in ttm_tt for ccs data Ramalingam C 2022-03-01 21:53 ` [Intel-gfx] " Ramalingam C 2022-03-02 12:58 ` Thomas Hellström 2022-03-02 12:58 ` [Intel-gfx] " Thomas Hellström 2022-03-01 21:53 ` [PATCH v2 4/4] drm/i915/migrate: Evict and restore the flatccs capable lmem obj Ramalingam C 2022-03-01 21:53 ` [Intel-gfx] " Ramalingam C 2022-03-03 8:04 ` Hellstrom, Thomas 2022-03-03 8:04 ` [Intel-gfx] " Hellstrom, Thomas 2022-03-02 1:51 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/ttm: Evict and store of compressed object (rev2) Patchwork 2022-03-02 1:53 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork 2022-03-02 2:23 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2022-03-02 8:28 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2022-03-02 15:31 ` [Intel-gfx] [PATCH v2 0/4] drm/i915/ttm: Evict and store of compressed object Das, Nirmoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220301215334.20543-1-ramalingam.c@intel.com \ --to=ramalingam.c@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=matthew.auld@intel.com \ --cc=thomas.hellstrom@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.