All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Ramalingam C <ramalingam.c@intel.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Cc: Matthew Auld <matthew.auld@intel.com>,
	Christian Koenig <christian.koenig@amd.com>
Subject: Re: [PATCH v2 3/4] drm/i915/gem: Extra pages in ttm_tt for ccs data
Date: Wed, 02 Mar 2022 13:58:42 +0100	[thread overview]
Message-ID: <4f9ed1b444ca8f861b9a8a179790b0287c6ae077.camel@linux.intel.com> (raw)
In-Reply-To: <20220301215334.20543-4-ramalingam.c@intel.com>

On Wed, 2022-03-02 at 03:23 +0530, Ramalingam C wrote:
> 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.

Nit: Again imperative wording, 


> 
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> cc: Christian Koenig <christian.koenig@amd.com>
> cc: Hellstrom Thomas <thomas.hellstrom@intel.com>

Reviewed by: Thomas Hellström <thomas.hellstrom@linux.intel.com>


> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 1a8262f5f692..c7a36861c38d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -20,6 +20,7 @@
>  #include "gem/i915_gem_ttm.h"
>  #include "gem/i915_gem_ttm_move.h"
>  #include "gem/i915_gem_ttm_pm.h"
> +#include "gt/intel_gpu_commands.h"
>  
>  #define I915_TTM_PRIO_PURGE     0
>  #define I915_TTM_PRIO_NO_PAGES  1
> @@ -255,12 +256,27 @@ static const struct i915_refct_sgt_ops
> tt_rsgt_ops = {
>         .release = i915_ttm_tt_release
>  };
>  
> +static inline bool
> +i915_gem_object_has_lmem_placement(struct drm_i915_gem_object *obj)
> +{
> +       int i;
> +
> +       for (i = 0; i < obj->mm.n_placements; i++)
> +               if (obj->mm.placements[i]->type ==
> INTEL_MEMORY_LOCAL)
> +                       return true;
> +
> +       return false;
> +}
> +
>  static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object
> *bo,
>                                          uint32_t page_flags)
>  {
> +       struct drm_i915_private *i915 = container_of(bo->bdev,
> typeof(*i915),
> +                                                    bdev);
>         struct ttm_resource_manager *man =
>                 ttm_manager_type(bo->bdev, bo->resource->mem_type);
>         struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> +       unsigned long ccs_pages = 0;
>         enum ttm_caching caching;
>         struct i915_ttm_tt *i915_tt;
>         int ret;
> @@ -283,7 +299,12 @@ static struct ttm_tt *i915_ttm_tt_create(struct
> ttm_buffer_object *bo,
>                 i915_tt->is_shmem = true;
>         }
>  
> -       ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching, 0);
> +       if (HAS_FLAT_CCS(i915) &&
> i915_gem_object_has_lmem_placement(obj))
> +               ccs_pages = DIV_ROUND_UP(DIV_ROUND_UP(bo->base.size,
> +                                                    
> NUM_BYTES_PER_CCS_BYTE),
> +                                        PAGE_SIZE);
> +
> +       ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching,
> ccs_pages);
>         if (ret)
>                 goto err_free;
>  



WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Ramalingam C <ramalingam.c@intel.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>
Cc: Matthew Auld <matthew.auld@intel.com>,
	Christian Koenig <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/gem: Extra pages in ttm_tt for ccs data
Date: Wed, 02 Mar 2022 13:58:42 +0100	[thread overview]
Message-ID: <4f9ed1b444ca8f861b9a8a179790b0287c6ae077.camel@linux.intel.com> (raw)
In-Reply-To: <20220301215334.20543-4-ramalingam.c@intel.com>

On Wed, 2022-03-02 at 03:23 +0530, Ramalingam C wrote:
> 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.

Nit: Again imperative wording, 


> 
> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> cc: Christian Koenig <christian.koenig@amd.com>
> cc: Hellstrom Thomas <thomas.hellstrom@intel.com>

Reviewed by: Thomas Hellström <thomas.hellstrom@linux.intel.com>


> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 1a8262f5f692..c7a36861c38d 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -20,6 +20,7 @@
>  #include "gem/i915_gem_ttm.h"
>  #include "gem/i915_gem_ttm_move.h"
>  #include "gem/i915_gem_ttm_pm.h"
> +#include "gt/intel_gpu_commands.h"
>  
>  #define I915_TTM_PRIO_PURGE     0
>  #define I915_TTM_PRIO_NO_PAGES  1
> @@ -255,12 +256,27 @@ static const struct i915_refct_sgt_ops
> tt_rsgt_ops = {
>         .release = i915_ttm_tt_release
>  };
>  
> +static inline bool
> +i915_gem_object_has_lmem_placement(struct drm_i915_gem_object *obj)
> +{
> +       int i;
> +
> +       for (i = 0; i < obj->mm.n_placements; i++)
> +               if (obj->mm.placements[i]->type ==
> INTEL_MEMORY_LOCAL)
> +                       return true;
> +
> +       return false;
> +}
> +
>  static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object
> *bo,
>                                          uint32_t page_flags)
>  {
> +       struct drm_i915_private *i915 = container_of(bo->bdev,
> typeof(*i915),
> +                                                    bdev);
>         struct ttm_resource_manager *man =
>                 ttm_manager_type(bo->bdev, bo->resource->mem_type);
>         struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> +       unsigned long ccs_pages = 0;
>         enum ttm_caching caching;
>         struct i915_ttm_tt *i915_tt;
>         int ret;
> @@ -283,7 +299,12 @@ static struct ttm_tt *i915_ttm_tt_create(struct
> ttm_buffer_object *bo,
>                 i915_tt->is_shmem = true;
>         }
>  
> -       ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching, 0);
> +       if (HAS_FLAT_CCS(i915) &&
> i915_gem_object_has_lmem_placement(obj))
> +               ccs_pages = DIV_ROUND_UP(DIV_ROUND_UP(bo->base.size,
> +                                                    
> NUM_BYTES_PER_CCS_BYTE),
> +                                        PAGE_SIZE);
> +
> +       ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching,
> ccs_pages);
>         if (ret)
>                 goto err_free;
>  



  reply	other threads:[~2022-03-02 12:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01 21:53 [PATCH v2 0/4] drm/i915/ttm: Evict and store of compressed object Ramalingam C
2022-03-01 21:53 ` [Intel-gfx] " 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 [this message]
2022-03-02 12:58     ` 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=4f9ed1b444ca8f861b9a8a179790b0287c6ae077.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=ramalingam.c@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: link
Be 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.