Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Jahagirdar, Akshata" <akshata.jahagirdar@intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <zbigniew.kempczynski@intel.com>
Subject: Re: [PATCH v2 1/1] drm/xe/xe2: Send flat_ccs value in struct drm_xe_query_config
Date: Tue, 26 Mar 2024 12:49:57 -0700	[thread overview]
Message-ID: <405708bd-7534-44ba-9ec9-9aaead4fea0b@intel.com> (raw)
In-Reply-To: <f2e72896-8524-44a5-bb75-ff277c50eaa6@intel.com>


On 3/26/2024 1:25 AM, Matthew Auld wrote:
> On 26/03/2024 10:10, Akshata Jahagirdar wrote:
>> Currently, we don't have any check in IGT testcases if platform supports
>> compression or not. Send this flat_ccs value as part of the struct
>> drm_xe_query_config so that we can read this value in the igt testcases
>> and proceed accordingly.
>
> AFAIK it's not valid to add uAPI just for an IGT. uAPI normally needs 
> a real open source user (like Mesa etc) with UMD acks. However if this 
> is going to be used by Mesa etc, how do they tell the difference 
> between "this device doesn't have flat-CCS" and "this KMD version 
> doesn't support FLAG_HAS_FLAT_CCS"?
>
Yeah, maybe we can add some checks using helper functions of debugfs to 
see if the file actually contains "flat-ccs" line.
> If userspace doesn't need this, then other option could be debugfs. Or 
> if this just a single test perhaps we can just dynamically check if 
> the CCS state is zero for compressed buffer at the start of the test?
>
I got your point, I will try to explore the debugfs and other 
suggestions that you provided.

I thought this was a better/cleaner solution than debugfs, but didn't 
realize the actual uAPI use-case here.

Thank you for your review.
-Akshata

>> Fixes: VLK-56136
>>
>> Signed-off-by: Akshata Jahagirdar <akshata.jahagirdar@intel.com>
>> ---
>>   drivers/gpu/drm/xe/xe_query.c | 3 +++
>>   include/uapi/drm/xe_drm.h     | 1 +
>>   2 files changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_query.c 
>> b/drivers/gpu/drm/xe/xe_query.c
>> index e80321b34918..8a3a3117491c 100644
>> --- a/drivers/gpu/drm/xe/xe_query.c
>> +++ b/drivers/gpu/drm/xe/xe_query.c
>> @@ -332,6 +332,9 @@ static int query_config(struct xe_device *xe, 
>> struct drm_xe_device_query *query)
>>       config->num_params = num_params;
>>       config->info[DRM_XE_QUERY_CONFIG_REV_AND_DEVICE_ID] =
>>           xe->info.devid | (xe->info.revid << 16);
>> +    if (xe->info.has_flat_ccs)
>> +        config->info[DRM_XE_QUERY_CONFIG_FLAGS] =
>> +            DRM_XE_QUERY_CONFIG_FLAG_HAS_FLAT_CCS;
>>       if (xe_device_get_root_tile(xe)->mem.vram.usable_size)
>>           config->info[DRM_XE_QUERY_CONFIG_FLAGS] =
>
> This tramples the previous value AFAICT, like when we have VRAM + CCS 
> on DG2. I think we need |= here.
>
>> DRM_XE_QUERY_CONFIG_FLAG_HAS_VRAM;
>> diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
>> index f44a19ae9333..08783234bae1 100644
>> --- a/include/uapi/drm/xe_drm.h
>> +++ b/include/uapi/drm/xe_drm.h
>> @@ -405,6 +405,7 @@ struct drm_xe_query_config {
>>   #define DRM_XE_QUERY_CONFIG_REV_AND_DEVICE_ID    0
>>   #define DRM_XE_QUERY_CONFIG_FLAGS            1
>>       #define DRM_XE_QUERY_CONFIG_FLAG_HAS_VRAM    (1 << 0)
>> +    #define DRM_XE_QUERY_CONFIG_FLAG_HAS_FLAT_CCS    (1 << 1)
>>   #define DRM_XE_QUERY_CONFIG_MIN_ALIGNMENT        2
>>   #define DRM_XE_QUERY_CONFIG_VA_BITS            3
>>   #define DRM_XE_QUERY_CONFIG_MAX_EXEC_QUEUE_PRIORITY    4

  reply	other threads:[~2024-03-26 19:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-26 10:10 [PATCH v2 0/1] Send flat_ccs value in struct drm_xe_query_config Akshata Jahagirdar
2024-03-25 22:21 ` ✓ CI.Patch_applied: success for " Patchwork
2024-03-25 22:21 ` ✓ CI.checkpatch: " Patchwork
2024-03-25 22:22 ` ✓ CI.KUnit: " Patchwork
2024-03-25 22:33 ` ✓ CI.Build: " Patchwork
2024-03-25 22:36 ` ✓ CI.Hooks: " Patchwork
2024-03-25 22:38 ` ✓ CI.checksparse: " Patchwork
2024-03-25 23:07 ` ✓ CI.BAT: " Patchwork
2024-03-26  5:46 ` [PATCH v2 0/1] " Zbigniew Kempczyński
2024-03-26 10:10 ` [PATCH v2 1/1] drm/xe/xe2: " Akshata Jahagirdar
2024-03-26  5:53   ` Zbigniew Kempczyński
2024-03-26  8:25   ` Matthew Auld
2024-03-26 19:49     ` Jahagirdar, Akshata [this message]
2024-03-27  4:54     ` Zbigniew Kempczyński
2024-03-27  8:54       ` Matthew Auld

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=405708bd-7534-44ba-9ec9-9aaead4fea0b@intel.com \
    --to=akshata.jahagirdar@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=zbigniew.kempczynski@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox