All of lore.kernel.org
 help / color / mirror / Atom feed
From: Riana Tauro <riana.tauro@intel.com>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH] drm/xe : Fix GT looping for standalone media
Date: Thu, 15 Jun 2023 10:12:04 +0530	[thread overview]
Message-ID: <80105db9-e10e-aec7-73b3-aa780f9d0fb5@intel.com> (raw)
In-Reply-To: <20230614175403.GI6953@mdroper-desk1.amr.corp.intel.com>



On 6/14/2023 11:24 PM, Matt Roper wrote:
> On Tue, Jun 13, 2023 at 02:39:45PM -0700, Matt Roper wrote:
>> On Tue, Jun 13, 2023 at 03:12:32PM +0530, Riana Tauro wrote:
>>> Currently the id of primary gt is set using gt_count and not
>>> the media gt.
>>>
>>> set gt->info.id of media gt using gt_count
>>>
>>> Signed-off-by: Riana Tauro <riana.tauro@intel.com>
>>> ---
>>>   drivers/gpu/drm/xe/xe_pci.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
>>> index bd1f59b49928..2991cf5365d5 100644
>>> --- a/drivers/gpu/drm/xe/xe_pci.c
>>> +++ b/drivers/gpu/drm/xe/xe_pci.c
>>> @@ -590,7 +590,7 @@ static int xe_info_init(struct xe_device *xe,
>>>   		 * up with platforms that support both together.
>>>   		 */
>>>   		drm_WARN_ON(&xe->drm, id != 0);
>>> -		gt->info.id = 1;
>>> +		gt->info.id = xe->info.gt_count++;
>>
>> 1 is always correct today since MTL is the only platform with a
>> standalone media GT, and it's a single-tile platform (so the GTs are
>> 0/1).  This will also be true for any future single-tile platforms with
>> standalone media.
>>
>> If/when we eventually have a platform that's both multi-tile _and_
>> multi-gt, we need to decide how we're going to identify GTs.  Since no
>> such platform exists today, we also don't know for sure whether every
>> tile will have both GTs, or whether only some of the tiles will have
>> multiple GTs.  It's not clear that using gt_count++ will necessarily be
>> the right thing to do; maybe we want to make primary GTs 2*tile and
>> media GTs 2*tile+1 (i.e., intentionally skip IDs if some of the tiles
>> have both and others do not).  We may also want to adjust how we
>> approach GT identification in the uapi in general --- maybe we don't
>> even want to give GTs a global ID anymore and instead want to move
>> toward identifying GT with a (tile_id, gt_id) tuple where gt_id is an
>> intra-tile number (i.e., 0=primary, 1=media).
>>
>> The current GT and tile series aimed to just preserve the existing uapi
>> without changes, and using an ID of 1 for media (with all the FIXME
>> comments in the code) does that for now.  But sometime soon we do need
>> to make a formal decision on exactly how we want to work with tiles and
>> GTs in the uapi, going forward and that needs to be something that we
>> loop in our userspace partners on; we can't just make the decision
>> ourselves on the kernel side.
> 
> So looking at this patch again, the important part isn't actually the ID
> of the GT (that's already being set correctly); what's important is that
> we need to bump the GT count again when initializing the media GT,
> otherwise gt_count will stay "1" forever, even when it should be 2.  So
> with an updated commit message that focuses on the gt_count rather than
> the ID,
> 
> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
> 
Thanks for the review Matt

Sorry for not being clear in the commit message. for_each_gt remains 
stuck at 1 and the media gt was not getting initialized causing an error.

Thanks
Riana
> I can make that tweak to the commit message while applying; no need to
> re-send.
> 
> 
> Matt
> 
>>
>>
>> Matt
>>
>>>   	}
>>>   
>>>   	return 0;
>>> -- 
>>> 2.40.0
>>>
>>
>> -- 
>> Matt Roper
>> Graphics Software Engineer
>> Linux GPU Platform Enablement
>> Intel Corporation
> 

      reply	other threads:[~2023-06-15  4:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-13  9:42 [Intel-xe] [PATCH] drm/xe : Fix GT looping for standalone media Riana Tauro
2023-06-13 10:33 ` [Intel-xe] ✓ CI.Patch_applied: success for " Patchwork
2023-06-13 10:33 ` [Intel-xe] ✓ CI.checkpatch: " Patchwork
2023-06-13 10:34 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-06-13 10:38 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-06-13 10:38 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-06-13 10:39 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-06-13 11:08 ` [Intel-xe] ○ CI.BAT: info " Patchwork
2023-06-13 18:58 ` [Intel-xe] [PATCH] " Matthew Brost
2023-06-13 21:39 ` Matt Roper
2023-06-14 17:54   ` Matt Roper
2023-06-15  4:42     ` Riana Tauro [this message]

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=80105db9-e10e-aec7-73b3-aa780f9d0fb5@intel.com \
    --to=riana.tauro@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.d.roper@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.