On 22-09-2023 19:17, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use the newly added drm_print_memory_stats helper to show memory
> utilisation of our objects in drm/driver specific fdinfo output.
>
> To collect the stats we walk the per memory regions object lists
> and accumulate objec
On 26-09-2023 21:12, Tvrtko Ursulin wrote:
>
> On 26/09/2023 16:29, Iddamsetty, Aravind wrote:
>> On 22-09-2023 19:16, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin
>>>
>>> At the moment memory region names are a bit too varied and too
>>> in
On 22-09-2023 19:16, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> At the moment memory region names are a bit too varied and too
> inconsistent to be used for ABI purposes, like for upcoming fdinfo
> memory stats.
>
> System memory can be either system or system-ttm. Local memory has the
On 22-09-2023 16:27, Tvrtko Ursulin wrote:
>
> On 22/09/2023 09:48, Iddamsetty, Aravind wrote:
>>
>>
>> On 21-09-2023 17:18, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin
>>>
>>> Use the newly added drm_print_memory_stats helper to show
On 21-09-2023 17:18, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use the newly added drm_print_memory_stats helper to show memory
> utilisation of our objects in drm/driver specific fdinfo output.
>
> To collect the stats we walk the per memory regions object lists
> and accumulate objec
On 03-08-2023 14:19, Tvrtko Ursulin wrote:
>
> On 03/08/2023 06:15, Iddamsetty, Aravind wrote:
>> On 27-07-2023 15:43, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin
>>>
>>> Use the newly added drm_print_memory_stats helper to show memory
>>> u
On 27-07-2023 15:43, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In order to show per client memory usage lets add some infrastructure
> which enables tracking buffer objects owned by clients.
>
> We add a per client list protected by a new per client lock and to support
> delayed destru
On 27-07-2023 15:43, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use the newly added drm_print_memory_stats helper to show memory
> utilisation of our objects in drm/driver specific fdinfo output.
>
> To collect the stats we walk the per memory regions object lists
> and accumulate objec
On 07-07-2023 18:32, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Account ring buffers and logical context space against the owning client
> memory usage stats.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_context.c | 13 +
> drivers/gpu/drm/i915/i
On 07-07-2023 18:32, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Account page table backing store against the owning client memory usage
> stats.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
On 07-07-2023 18:32, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> To enable accounting of indirect client memory usage (such as page tables)
> in the following patch, lets start recording the creator of each PPGTT.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_
On 10-07-2023 18:50, Tvrtko Ursulin wrote:
>
> On 10/07/2023 11:44, Iddamsetty, Aravind wrote:
>> On 07-07-2023 18:32, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin
>>>
>>> In order to show per client memory usage lets add some infrastructure
>>
On 07-07-2023 18:32, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In order to show per client memory usage lets add some infrastructure
> which enables tracking buffer objects owned by clients.
>
> We add a per client list protected by a new per client lock and to support
> delayed destru
On 06-06-2023 19:34, Tomer Tayar wrote:
> On 05/06/2023 20:18, Iddamsetty, Aravind wrote:
>>
>> On 04-06-2023 22:37, Tomer Tayar wrote:
>>> On 26/05/2023 19:20, Aravind Iddamsetty wrote:
>>>> Define the netlink commands and attributes that can be comm
On 09-06-2023 17:41, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> I need a new flavour of the drm_gem_prime_fd_to_handle helper, one which
> will return a reference to a newly created GEM objects (if created), in
> order to enable tracking of imported i915 GEM objects in the following
> pa
On 08-06-2023 20:21, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In order to show per client memory usage lets start tracking which
> objects belong to which clients.
>
> We start with objects explicitly created by object creation UAPI and
> track it on a new per client lists, protected
On 05-06-2023 22:17, Alex Deucher wrote:
> Adding the relevant AMD folks for RAS. We currently expose RAS via
> sysfs, but also have an event interface in KFD which may be somewhat
> similar to this.
>
> If we were to converge on a common RAS interface, would we want to
> look at any commonali
On 04-06-2023 22:39, Tomer Tayar wrote:
> On 26/05/2023 19:20, Aravind Iddamsetty wrote:
>> Use the generic netlink(genl) subsystem to expose the RAS counters to
>> userspace. We define a family structure and operations and register to
>> genl subsystem and these callbacks will be invoked by gen
On 04-06-2023 22:37, Tomer Tayar wrote:
> On 26/05/2023 19:20, Aravind Iddamsetty wrote:
>> Define the netlink commands and attributes that can be commonly used
>> across by drm drivers.
>>
>> Signed-off-by: Aravind Iddamsetty
>> ---
>> include/uapi/drm/drm_netlink.h | 68
On 04-06-2023 22:37, Tomer Tayar wrote:
> On 26/05/2023 19:20, Aravind Iddamsetty wrote:
>> Our hardware supports RAS(Reliability, Availability, Serviceability) by
>> exposing a set of error counters which can be used by observability
>> tools to take corrective actions or repairs. Traditionally
On 06-02-2023 15:21, Tvrtko Ursulin wrote:
>
>
> On 03/02/2023 13:52, Aravind Iddamsetty wrote:
>> Obj flags for shmem objects is not being set correctly. Fixes in setting
>> BO_ALLOC_USER flag which applies to shmem objs as well.
>>
>> Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally flush
On 03-02-2023 17:40, Tvrtko Ursulin wrote:
>
>
> On 03/02/2023 11:57, Aravind Iddamsetty wrote:
>> Obj flags for shmem objects is not being set correctly.
>>
>> Cc: Matthew Auld
>> Signed-off-by: Aravind Iddamsetty
>
> Could even be:
>
> Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally
On 03-02-2023 17:42, Matthew Auld wrote:
> On 03/02/2023 11:57, Aravind Iddamsetty wrote:
>> Obj flags for shmem objects is not being set correctly.
>>
>> Cc: Matthew Auld
>> Signed-off-by: Aravind Iddamsetty
>
> Subject should have "drm/i915:" prefix.
My bad missed that.
>
> This is also a
On 29-11-2022 15:41, Tvrtko Ursulin wrote:
>
> On 22/11/2022 07:01, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared between media and
On 29-11-2022 11:24, Lucas De Marchi wrote:
> On Wed, Nov 23, 2022 at 09:47:03AM +0530, Iddamsetty, Aravind wrote:
>>
>>
>> On 23-11-2022 05:29, Matt Roper wrote:
>>> On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
>>>> On XE_LPM+
On 23-11-2022 05:29, Matt Roper wrote:
> On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared betw
On 19-11-2022 04:22, Matt Roper wrote:
> On Tue, Nov 15, 2022 at 08:34:54PM +0530, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared betw
On 31-10-2022 23:16, Matt Roper wrote:
> On Mon, Oct 31, 2022 at 06:01:11PM +0530, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared betw
On 31-10-2022 23:16, Matt Roper wrote:
> On Mon, Oct 31, 2022 at 06:01:11PM +0530, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared betw
Hi Lucas,
> -Original Message-
> From: De Marchi, Lucas
> Sent: Friday, November 4, 2022 12:36 PM
> To: Iddamsetty, Aravind
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Media GT and Render GT s
On 19-10-2022 06:14, John Harrison wrote:
> On 10/12/2022 17:03, Daniele Ceraolo Spurio wrote:
>> From: Aravind Iddamsetty
>>
>> With MTL standalone media architecture the wopcm layout has changed with
>> separate partitioning in WOPCM for GCD/GT GuC and SA Media GuC. The size
> What is GCD?
G
On 13-10-2022 05:33, Daniele Ceraolo Spurio wrote:
> On MTL the primary GT doesn't have any media capabilities, so no video
> engines and no HuC. We must therefore skip the HuC fetch and load on
> that specific case. Given that other multi-GT platforms might have HuC
> on the primary GT, we can'
On 28-09-2022 03:52, Matt Roper wrote:
> On Tue, Sep 27, 2022 at 12:14:24AM +0530, Aravind Iddamsetty wrote:
>> As an integrated GPU, MTL does not have local memory and
>> HAS_LMEM() returns false. However the platform's stolen memory
>> is presented via BAR2 (i.e., the BAR we traditionally con
On 23-09-2022 03:41, Daniele Ceraolo Spurio wrote:
> On MTL the primary GT doesn't have any media capabilities, so no video
> engines and no HuC. We must therefore skip the HuC fetch and load on
> that specific case. Given that other multi-GT platforms might have HuC
> on the primary GT, we can'
On 22-09-2022 19:26, Lucas De Marchi wrote:
> On Wed, Sep 21, 2022 at 12:00:38PM +0530, Iddamsetty, Aravind wrote:
>> replying here for earlier comments too.
>>
>> On 21-09-2022 01:35, Lucas De Marchi wrote:
>>> On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De
On 20-09-2022 13:05, Jani Nikula wrote:
> On Tue, 20 Sep 2022, Aravind Iddamsetty wrote:
>> As an integrated GPU, MTL does not have local memory and
>> HAS_LMEM() returns false. However the platform's stolen memory
>> is presented via BAR2 (i.e., the BAR we traditionally consider
>> to be the
replying here for earlier comments too.
On 21-09-2022 01:35, Lucas De Marchi wrote:
> On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De Marchi wrote:
>> On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
>>> As an integrated GPU, MTL does not have local memory and
>>> HAS_LMEM()
On 16-09-2022 02:09, Lucas De Marchi wrote:
> Add some helpers: adjust_stolen(), request_smem_stolen_() and
> init_reserved_stolen() that are now called by i915_gem_init_stolen() to
> initialize each part of the Data Stolen Memory region. Main goal is to
> split the reserved part, also known as
On 16-09-2022 02:09, Lucas De Marchi wrote:
> DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
> of the base address of stolen. For the supported platforms bits 0-19 are
> zero but that may not be true in future. Add the missing mask.
>
> Signed-off-by: Lucas De Marchi
On 16-09-2022 02:09, Lucas De Marchi wrote:
> Reduce possible side effects of assigning the region and bailing out due
> to errors.
>
> Signed-off-by: Lucas De Marchi
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index acc561c0f0
On 07-09-2022 05:19, Matt Roper wrote:
> Xe_LPM+ platforms have "standalone media." I.e., the media unit is
> designed as an additional GT with its own engine list, GuC, forcewake,
> etc. Let's allow platforms to include media GTs in their device info.
>
> v2:
> - Simplify GSI register handl
_gt_definition;
>
> /* Keep in gen based order, and chronological order within a gen */
> enum intel_platform {
> @@ -252,6 +253,8 @@ struct intel_device_info {
>
> unsigned int dma_mask_size; /* available DMA address bits */
>
> + const struct intel_gt_definition *extra_gt_list;
> +
> u8 gt; /* GT number, 0 if undefined */
>
> #define DEFINE_FLAG(name) u8 name:1
> diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> index f5904e659ef2..915d58ba383e 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> @@ -115,6 +115,7 @@ static struct dev_pm_domain pm_domain = {
> static void mock_gt_probe(struct drm_i915_private *i915)
> {
> i915->gt[0] = &i915->gt0;
> + i915->gt[0]->name = "Mock GT";
> }
>
> struct drm_i915_private *mock_gem_device(void)
LGTM.
Reviewed-by: Aravind Iddamsetty
Aravind.
On 07-09-2022 05:19, Matt Roper wrote:
> The aux table invalidation registers are a bit unique --- they're
> engine-centric registers that reside in the GSI register space rather
> than within the engines' regular MMIO ranges. That means that when
> issuing invalidation on engines in the standa
On 03-09-2022 05:02, Matt Roper wrote:
> GT non-engine registers (referred to as "GSI" registers by the spec)
> have the same relative offsets on standalone media as they do on the
> primary GT, just with an additional "GSI offset" added to their MMIO
> address. If we store this GSI offset in t
On 03-09-2022 05:02, Matt Roper wrote:
> Xe_LPM+ platforms have "standalone media." I.e., the media unit is
> designed as an additional GT with its own engine list, GuC, forcewake,
> etc. Let's allow platforms to include media GTs in their device info.
>
> v2:
> - Simplify GSI register handl
45 matches
Mail list logo
