Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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