public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Lionel Landwerlin <lionel.g.landwerlin@intel.com>,
	Michel Thierry <michel.thierry@intel.com>,
	Michal Wajdeczko <michal.wajdeczko@intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 06/21] drm/i915/guc: Use guc_class instead of engine_class in fw interface
Date: Thu, 30 Aug 2018 15:34:43 -0700	[thread overview]
Message-ID: <5dc24ee1-6da5-71aa-e845-0587719b5f83@intel.com> (raw)
In-Reply-To: <1779168b-4930-ac52-0bb4-20695478cf81@intel.com>



On 29/08/18 17:16, Lionel Landwerlin wrote:
> On 29/08/2018 20:58, Michel Thierry wrote:
>> +Lionel
>> (please see below as this touches the lrca format & relates to OA 
>> reporting too)
>>
>> On 8/29/2018 12:10 PM, Michal Wajdeczko wrote:
>>> Until now the GuC and HW engine class has been the same, which allowed
>>> us to use them interchangeable. But it is better to start doing the
>>> right thing and use the GuC definitions for the firmware interface.
>>>
>>> We also keep the same class id in the ctx descriptor to be able to have
>>> the same values in the driver and firmware logs.
>>>
>>> Signed-off-by: Michel Thierry <michel.thierry@intel.com>
>>> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>> Cc: Michel Thierry <michel.thierry@intel.com>
>>> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>>> Cc: Tomasz Lis <tomasz.lis@intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/intel_engine_cs.c  | 13 +++++++++++++
>>>   drivers/gpu/drm/i915/intel_guc_fwif.h   |  7 +++++++
>>>   drivers/gpu/drm/i915/intel_lrc.c        | 10 +++++++++-
>>>   drivers/gpu/drm/i915/intel_ringbuffer.h |  2 ++
>>>   4 files changed, 31 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
>>> b/drivers/gpu/drm/i915/intel_engine_cs.c
>>> index 1a34e8f..bc81354 100644
>>> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
>>> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
>>> @@ -85,6 +85,7 @@ struct engine_info {
>>>       unsigned int hw_id;
>>>       unsigned int uabi_id;
>>>       u8 class;
>>> +    u8 guc_class;
>>>       u8 instance;
>>>       /* mmio bases table *must* be sorted in reverse gen order */
>>>       struct engine_mmio_base {
>>> @@ -98,6 +99,7 @@ struct engine_info {
>>>           .hw_id = RCS_HW,
>>>           .uabi_id = I915_EXEC_RENDER,
>>>           .class = RENDER_CLASS,
>>> +        .guc_class = GUC_RENDER_CLASS,
>>>           .instance = 0,
>>>           .mmio_bases = {
>>>               { .gen = 1, .base = RENDER_RING_BASE }
>>> @@ -107,6 +109,7 @@ struct engine_info {
>>>           .hw_id = BCS_HW,
>>>           .uabi_id = I915_EXEC_BLT,
>>>           .class = COPY_ENGINE_CLASS,
>>> +        .guc_class = GUC_BLITTER_CLASS,
>>>           .instance = 0,
>>>           .mmio_bases = {
>>>               { .gen = 6, .base = BLT_RING_BASE }
>>> @@ -116,6 +119,7 @@ struct engine_info {
>>>           .hw_id = VCS_HW,
>>>           .uabi_id = I915_EXEC_BSD,
>>>           .class = VIDEO_DECODE_CLASS,
>>> +        .guc_class = GUC_VIDEO_CLASS,
>>>           .instance = 0,
>>>           .mmio_bases = {
>>>               { .gen = 11, .base = GEN11_BSD_RING_BASE },
>>> @@ -127,6 +131,7 @@ struct engine_info {
>>>           .hw_id = VCS2_HW,
>>>           .uabi_id = I915_EXEC_BSD,
>>>           .class = VIDEO_DECODE_CLASS,
>>> +        .guc_class = GUC_VIDEO_CLASS,
>>>           .instance = 1,
>>>           .mmio_bases = {
>>>               { .gen = 11, .base = GEN11_BSD2_RING_BASE },
>>> @@ -137,6 +142,7 @@ struct engine_info {
>>>           .hw_id = VCS3_HW,
>>>           .uabi_id = I915_EXEC_BSD,
>>>           .class = VIDEO_DECODE_CLASS,
>>> +        .guc_class = GUC_VIDEO_CLASS,
>>>           .instance = 2,
>>>           .mmio_bases = {
>>>               { .gen = 11, .base = GEN11_BSD3_RING_BASE }
>>> @@ -146,6 +152,7 @@ struct engine_info {
>>>           .hw_id = VCS4_HW,
>>>           .uabi_id = I915_EXEC_BSD,
>>>           .class = VIDEO_DECODE_CLASS,
>>> +        .guc_class = GUC_VIDEO_CLASS,
>>>           .instance = 3,
>>>           .mmio_bases = {
>>>               { .gen = 11, .base = GEN11_BSD4_RING_BASE }
>>> @@ -155,6 +162,7 @@ struct engine_info {
>>>           .hw_id = VECS_HW,
>>>           .uabi_id = I915_EXEC_VEBOX,
>>>           .class = VIDEO_ENHANCEMENT_CLASS,
>>> +        .guc_class = GUC_VIDEOENHANCE_CLASS,
>>>           .instance = 0,
>>>           .mmio_bases = {
>>>               { .gen = 11, .base = GEN11_VEBOX_RING_BASE },
>>> @@ -165,6 +173,7 @@ struct engine_info {
>>>           .hw_id = VECS2_HW,
>>>           .uabi_id = I915_EXEC_VEBOX,
>>>           .class = VIDEO_ENHANCEMENT_CLASS,
>>> +        .guc_class = GUC_VIDEOENHANCE_CLASS,
>>>           .instance = 1,
>>>           .mmio_bases = {
>>>               { .gen = 11, .base = GEN11_VEBOX2_RING_BASE }
>>> @@ -276,6 +285,9 @@ static void __sprint_engine_name(char *name, 
>>> const struct engine_info *info)
>>>       if (GEM_WARN_ON(info->class > MAX_ENGINE_CLASS))
>>>           return -EINVAL;
>>>   +    if (GEM_WARN_ON(info->guc_class >= GUC_MAX_ENGINE_CLASSES))
>>> +        return -EINVAL;
>>> +
>>>       if (GEM_WARN_ON(info->instance > MAX_ENGINE_INSTANCE))
>>>           return -EINVAL;
>>>   @@ -291,6 +303,7 @@ static void __sprint_engine_name(char *name, 
>>> const struct engine_info *info)
>>>       engine->i915 = dev_priv;
>>>       __sprint_engine_name(engine->name, info);
>>>       engine->hw_id = engine->guc_id = info->hw_id;
>>> +    engine->guc_class = info->guc_class;
>>>       engine->mmio_base = __engine_mmio_base(dev_priv, 
>>> info->mmio_bases);
>>>       engine->class = info->class;
>>>       engine->instance = info->instance;
>>> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
>>> b/drivers/gpu/drm/i915/intel_guc_fwif.h
>>> index 963da91..5b7a05b 100644
>>> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
>>> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
>>> @@ -39,6 +39,13 @@
>>>   #define GUC_VIDEO_ENGINE2        4
>>>   #define GUC_MAX_ENGINES_NUM        (GUC_VIDEO_ENGINE2 + 1)
>>>   +#define GUC_RENDER_CLASS    0
>>> +#define GUC_VIDEO_CLASS        1
>>> +#define GUC_VIDEOENHANCE_CLASS    2
>>> +#define GUC_BLITTER_CLASS    3
>>> +#define GUC_RESERVED_CLASS    4
>>> +#define GUC_MAX_ENGINE_CLASSES    (GUC_RESERVED_CLASS + 1)
>>> +
>>>   /* Work queue item header definitions */
>>>   #define WQ_STATUS_ACTIVE        1
>>>   #define WQ_STATUS_SUSPENDED        2
>>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
>>> b/drivers/gpu/drm/i915/intel_lrc.c
>>> index f8ceb9c..f4b9972 100644
>>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>>> @@ -249,7 +249,15 @@ static inline bool need_preempt(const struct 
>>> intel_engine_cs *engine,
>>>             /* TODO: decide what to do with SW counter (bits 55-60) */
>>>   -        desc |= (u64)engine->class << GEN11_ENGINE_CLASS_SHIFT;
>>> +        /*
>>> +         * Although GuC will never see this upper part as it fills
>>> +         * its own descriptor, using the guc_class here will help keep
>>> +         * the i915 and firmware logs in sync.
>>> +         */
>>> +        if (HAS_GUC_SCHED(ctx->i915))
>>> +            desc |= (u64)engine->guc_class << GEN11_ENGINE_CLASS_SHIFT;
>>> +        else
>>> +            desc |= (u64)engine->class << GEN11_ENGINE_CLASS_SHIFT;
>>>                                   /* bits 61-63 */
>>
>> OA also uses this upper part (see oa_get_render_ctx_id), so it's 
>> something to be aware of.
>>
>> My opinion is that it's useful to have the lrca matching the firmware 
>> logs, but OA should account of this change at it receives what the fw 
>> sent to the hw. Which one is more important is for others to decide 
>> (plus it only becomes a problem when engine-class and guc-class start 
>> to deviate).
>>
>> Acked-by: Michel Thierry <michel.thierry@intel.com>
>>
>> -Michel
> 
> 
> If GuC still behaves the same as the Gen9 firmware I was testing with, 
> parts of the upper 32bits of the descriptor will end up in HW.
> 
> Just make sure i915_perf.c is in sync with intel_lrc.c and it should be 
> fine :)
> 

Not sure about having i915_perf.c is in sync with intel_lrc.c. As Michel 
said, GuC will submit to the HW using the "real" IDs (i.e. the ones used 
in intel_lrc the non-guc path) so I would expect those to show up in 
perf counters but in guc logs we have the "fake" ones (i.e. the ones 
using the guc_ids). In this patch intel_lrc uses the guc_ids and I don't 
think we want that for perf.
The ids are currently the same in both paths so testing is not going to 
show any issue with this until they diverge.

Thanks,
Daniele

> 
>>
>>
>>>       } else {
>>>           GEM_BUG_ON(ctx->hw_id >= BIT(GEN8_CTX_ID_WIDTH));
>>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
>>> b/drivers/gpu/drm/i915/intel_ringbuffer.h
>>> index 3f6920d..f47009f 100644
>>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
>>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
>>> @@ -350,7 +350,9 @@ struct intel_engine_cs {
>>>         enum intel_engine_id id;
>>>       unsigned int hw_id;
>>> +
>>>       unsigned int guc_id;
>>> +    u8 guc_class;
>>>         u8 uabi_id;
>>>       u8 uabi_class;
>>>
>>
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-08-30 22:34 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-29 19:10 [PATCH 00/21] New GuC ABI Michal Wajdeczko
2018-08-29 19:10 ` [PATCH 01/21] drm/i915/guc: Update GuC power domain states Michal Wajdeczko
2018-08-29 20:57   ` Daniele Ceraolo Spurio
2018-08-29 22:43     ` Michal Wajdeczko
2018-08-29 19:10 ` [PATCH 02/21] drm/i915/guc: Don't allow GuC submission on pre-Gen11 Michal Wajdeczko
2018-08-29 19:16   ` Srivatsa, Anusha
2018-08-30 22:58   ` John Spotswood
2018-09-06  8:28   ` Joonas Lahtinen
2018-09-06  8:29   ` Joonas Lahtinen
2018-08-29 19:10 ` [PATCH 03/21] drm/i915/guc: Simplify preparation of GuC parameter block Michal Wajdeczko
2018-08-30 22:58   ` John Spotswood
2018-09-06  8:32   ` Joonas Lahtinen
2018-08-29 19:10 ` [PATCH 04/21] drm/i915/guc: Support dual Gen9/Gen11 parameters block Michal Wajdeczko
2018-08-30 22:58   ` John Spotswood
2018-09-06  8:39   ` Joonas Lahtinen
2018-08-29 19:10 ` [PATCH 05/21] drm/i915/guc: Update sample-forcewake command Michal Wajdeczko
2018-08-29 21:52   ` Daniele Ceraolo Spurio
2018-08-29 22:31     ` Michal Wajdeczko
2018-08-29 19:10 ` [PATCH 06/21] drm/i915/guc: Use guc_class instead of engine_class in fw interface Michal Wajdeczko
2018-08-29 19:58   ` Michel Thierry
2018-08-30  0:16     ` Lionel Landwerlin
2018-08-30 13:29       ` Lis, Tomasz
2018-08-30 14:16         ` Lis, Tomasz
2018-08-30 14:56         ` Lionel Landwerlin
2018-08-30 22:34       ` Daniele Ceraolo Spurio [this message]
2018-09-06  8:55   ` Joonas Lahtinen
2018-08-29 19:15 ` [PATCH 07/21] drm/i915/guc: New GuC ADS object definition Michal Wajdeczko
2018-08-29 19:16 ` [PATCH 08/21] drm/i915/guc: Make use of the SW counter field in the context descriptor Michal Wajdeczko
2018-08-30  0:08   ` Lionel Landwerlin
2018-08-30 14:15     ` Lis, Tomasz
2018-08-31 15:31       ` Lis, Tomasz
2018-08-29 19:17 ` [PATCH 09/21] drm/i915/guc: New GuC IDs based on engine class and instance Michal Wajdeczko
2018-08-29 19:18 ` [PATCH 10/21] drm/i915: Add hooks for (per-engine) context allocation/update/free Michal Wajdeczko
2018-08-29 19:18   ` [PATCH 11/21] drm/i915/guc: New GuC stage descriptors Michal Wajdeczko
2018-08-29 23:14     ` Daniele Ceraolo Spurio
2018-10-12 18:25     ` [RFC] " Daniele Ceraolo Spurio
2018-10-17 18:42       ` Lis, Tomasz
2018-10-18 21:07         ` Daniele Ceraolo Spurio
2018-08-29 19:18   ` [PATCH 12/21] drm/i915/guc: New GuC workqueue item submission mechanism Michal Wajdeczko
2018-08-29 19:18   ` [PATCH 13/21] drm/i915/guc: Add support for resume-parsing wq item Michal Wajdeczko
2018-08-29 19:18   ` [PATCH 14/21] drm/i915/guc: New reset-engine command Michal Wajdeczko
2018-08-29 19:18   ` [PATCH 15/21] drm/i915/guc: Support for extended GuC notification messages Michal Wajdeczko
2018-08-29 19:18   ` [PATCH 16/21] drm/i915/guc: New engine-reset-complete message Michal Wajdeczko
2018-08-29 19:18   ` [PATCH 17/21] drm/i915/guc: New GuC interrupt register for Gen11 Michal Wajdeczko
2018-08-29 19:18   ` [PATCH 18/21] drm/i915/guc: New GuC scratch registers " Michal Wajdeczko
2018-08-29 19:18   ` [PATCH 19/21] drm/i915/huc: New HuC status register " Michal Wajdeczko
2018-08-30 22:59     ` John Spotswood
2018-08-29 19:19 ` [PATCH 20/21] drm/i915/guc: Enable command transport buffers " Michal Wajdeczko
2018-08-29 19:19   ` [PATCH 21/21] HAX Don't enable GuC submission on pre-Gen11 even if forced Michal Wajdeczko

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=5dc24ee1-6da5-71aa-e845-0587719b5f83@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lionel.g.landwerlin@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=michel.thierry@intel.com \
    --cc=rodrigo.vivi@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