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
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 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
_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:
> 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
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 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 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 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 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 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 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: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 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 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 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 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
>
> 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 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
>
> 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 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 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 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 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 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:
> 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
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 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
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 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 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
> -Original Message-
> From: Roper, Matthew D
> Sent: Saturday, October 1, 2022 1:11 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Iddamsetty, Aravind
> Subject: Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: enable local
> stolen memory (rev5)
>
>
On 29-11-2022 01:22, Yang, Fei wrote:
>> From: Iddamsetty, Aravind
>> Sent: Monday, November 28, 2022 2:14 AM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: De Marchi, Lucas ; Roper, Matthew D
>> ; Yang, Fei
>> Subject: [PATCH 2/3] drm/i915/mtl: Defin
On 29-11-2022 01:57, Lucas De Marchi wrote:
> On Mon, Nov 28, 2022 at 03:43:51PM +0530, Aravind Iddamsetty wrote:
>> Add a separate PTE encode function for MTL. The number of PAT registers
>> have increased to 16 on MTL. All 16 PAT registers are available for
>> PPGTT mapped pages, but only the
On 29-11-2022 01:49, Lucas De Marchi wrote:
> On Mon, Nov 28, 2022 at 03:43:52PM +0530, Aravind Iddamsetty wrote:
>> From: Pallavi Mishra
>>
>> Caching mode for an object shall be selected via upcoming VM_BIND
>> interface.
>
> last I've heard there was no plan to support this through VM_BIND.
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 29-11-2022 01:49, Lucas De Marchi wrote:
> On Mon, Nov 28, 2022 at 03:43:52PM +0530, Aravind Iddamsetty wrote:
>> From: Pallavi Mishra
>>
>> Caching mode for an object shall be selected via upcoming VM_BIND
>> interface.
>
> last I've heard there was no plan to support this through VM_BIND.
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
please ignore this series will be sending a new one. some how patchwork
didn't pick up this neatly.
Thanks,
Aravind.
On 06-12-2022 13:07, Aravind Iddamsetty wrote:
> From: Madhumitha Tolakanahalli Pradeep
>
>
> On MTL due to the introduction of L4 cache, coherency and cacheability
> selections
On 07-12-2022 00:09, Lucas De Marchi wrote:
> On Tue, Dec 06, 2022 at 01:38:53PM +0530, Iddamsetty, Aravind wrote:
>> please ignore this series will be sending a new one. some how patchwork
>> didn't pick up this neatly.
>
> Patchwork makes a mess if you do --in-r
On 07-12-2022 04:21, Matt Roper wrote:
> On Tue, Dec 06, 2022 at 01:07:27PM +0530, Aravind Iddamsetty wrote:
>> New platforms will use different encode functions.
>
> You may want to elaborate slightly. E.g., something like
>
> "Future patches will introduce new platform-specific page table e
On 07-12-2022 05:09, Matt Roper wrote:
> On Tue, Dec 06, 2022 at 01:07:28PM +0530, Aravind Iddamsetty wrote:
>> Add a separate PTE encode function for MTL. The number of PAT registers
>> have increased to 16 on MTL. All 16 PAT registers are available for
>> PPGTT mapped pages, but only the lower
On 07-12-2022 23:41, Matt Roper wrote:
> On Wed, Dec 07, 2022 at 12:56:44PM +0530, Iddamsetty, Aravind wrote:
>>
>>
>> On 07-12-2022 05:09, Matt Roper wrote:
>>> On Tue, Dec 06, 2022 at 01:07:28PM +0530, Aravind Iddamsetty wrote:
>>>> Add a separate
On 07-12-2022 05:19, Matt Roper wrote:
> On Tue, Dec 06, 2022 at 01:57:39PM +0530, Aravind Iddamsetty wrote:
>> From: Pallavi Mishra
>>
>> It's a noop on all new platforms starting from MTL.
>
> To me, saying "it's a noop" implies that the ioctl will succeed and
> silently do nothing, which is
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 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
Hi Lucas,
> -Original Message-
> From: De Marchi, Lucas
> Sent: Friday, November 4, 2022 12:36 PM
> To: Iddamsetty, Aravind
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/mtl: Media GT and Render GT s
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
On 15-11-2022 13:38, Himal Prasad Ghimiray wrote:
> Export lmem maximum memory bandwidth to the userspace via sysfs.
>
> Signed-off-by: Himal Prasad Ghimiray
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/i915_sysfs.c | 27 +++
> 2 files chan
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 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
52 matches
Mail list logo
