From: Matthew Auld <matthew.auld@intel.com>
To: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Cc: Akshata Jahagirdar <akshata.jahagirdar@intel.com>,
intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2 1/1] drm/xe/xe2: Send flat_ccs value in struct drm_xe_query_config
Date: Wed, 27 Mar 2024 08:54:10 +0000 [thread overview]
Message-ID: <54ffa436-eb11-4376-81f5-8d449c3d66b5@intel.com> (raw)
In-Reply-To: <20240327045410.kjf3sspjfpwe7blh@zkempczy-mobl2>
On 27/03/2024 04:54, Zbigniew Kempczyński wrote:
> On Tue, Mar 26, 2024 at 08:25:56AM +0000, 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"?
>>
>> 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?
>
> Just for making sure - is ctrl-surf-copy behavior defined if there's no
> flat ccs?
Yeah, claim is that HW will never compress anything, writes to CCS are
dropped and reads from CCS return zero. KMD should also skip any CCS
related stuff.
>
> --
> Zbigniew
>>
>>> 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
prev parent reply other threads:[~2024-03-27 8:54 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
2024-03-27 4:54 ` Zbigniew Kempczyński
2024-03-27 8:54 ` Matthew Auld [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=54ffa436-eb11-4376-81f5-8d449c3d66b5@intel.com \
--to=matthew.auld@intel.com \
--cc=akshata.jahagirdar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--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