Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org,
	"Michał Winiarski" <michal.winiarski@intel.com>,
	"Matt Roper" <matthew.d.roper@intel.com>
Subject: Re: [PATCH 3/5] drm/xe: Avoid reading RMW registers in emit_wa_job
Date: Mon, 3 Mar 2025 19:47:50 +0100	[thread overview]
Message-ID: <64899758-d054-4f0c-a38f-8931473bada7@intel.com> (raw)
In-Reply-To: <3vm7izwczds45yaktuljfpges6rwsf27afgn7esuo6mdwontm5@vqtj3zkmnlmp>



On 03.03.2025 19:06, Lucas De Marchi wrote:
> On Mon, Mar 03, 2025 at 06:35:20PM +0100, Michal Wajdeczko wrote:
>> To allow VFs properly handle LRC WAs, we should postpone doing
>> all RMW register operations and let them be run by the engine
>> itself, since attempt to perform read registers from within the
>> driver will fail on the VF. Use MI_MATH and ALU for that.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Michał Winiarski <michal.winiarski@intel.com>
>> Cc: Matt Roper <matthew.d.roper@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_gt.c | 84 ++++++++++++++++++++++++++++----------
>> 1 file changed, 63 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
>> index 10a9e3c72b36..8068b4bc0a09 100644
>> --- a/drivers/gpu/drm/xe/xe_gt.c
>> +++ b/drivers/gpu/drm/xe/xe_gt.c
>> @@ -12,8 +12,10 @@
>>
>> #include <generated/xe_wa_oob.h>
>>
>> +#include "instructions/xe_alu_commands.h"
>> #include "instructions/xe_gfxpipe_commands.h"
>> #include "instructions/xe_mi_commands.h"
>> +#include "regs/xe_engine_regs.h"
>> #include "regs/xe_gt_regs.h"
>> #include "xe_assert.h"
>> #include "xe_bb.h"
>> @@ -176,15 +178,6 @@ static int emit_nop_job(struct xe_gt *gt, struct
>> xe_exec_queue *q)
>>     return 0;
>> }
>>
>> -/*
>> - * Convert back from encoded value to type-safe, only to be used when
>> reg.mcr
>> - * is true
>> - */
>> -static struct xe_reg_mcr to_xe_reg_mcr(const struct xe_reg reg)
>> -{
>> -    return (const struct xe_reg_mcr){.__reg.raw = reg.raw };
>> -}
>> -
>> static int emit_wa_job(struct xe_gt *gt, struct xe_exec_queue *q)
>> {
>>     struct xe_reg_sr *sr = &q->hwe->reg_lrc;
>> @@ -194,6 +187,7 @@ static int emit_wa_job(struct xe_gt *gt, struct
>> xe_exec_queue *q)
>>     struct xe_bb *bb;
>>     struct dma_fence *fence;
>>     long timeout;
>> +    int count_rmw = 0;
>>     int count = 0;
>>
>>     if (q->hwe->class == XE_ENGINE_CLASS_RENDER)
>> @@ -206,30 +200,32 @@ static int emit_wa_job(struct xe_gt *gt, struct
>> xe_exec_queue *q)
>>     if (IS_ERR(bb))
>>         return PTR_ERR(bb);
>>
>> -    xa_for_each(&sr->xa, idx, entry)
>> -        ++count;
>> +    /* count RMW registers as those will be handled separately */
>> +    xa_for_each(&sr->xa, idx, entry) {
>> +        if (entry->reg.masked || entry->clr_bits == ~0)
>> +            ++count;
>> +        else
>> +            ++count_rmw;
>> +    }
>>
>> -    if (count) {
>> +    if (count || count_rmw)
>>         xe_gt_dbg(gt, "LRC WA %s save-restore batch\n", sr->name);
>>
>> +    if (count) {
>> +        /* emit single LRI with all non RMW regs */
>> +
>>         bb->cs[bb->len++] = MI_LOAD_REGISTER_IMM |
>> MI_LRI_NUM_REGS(count);
>>
>>         xa_for_each(&sr->xa, idx, entry) {
>>             struct xe_reg reg = entry->reg;
>> -            struct xe_reg_mcr reg_mcr = to_xe_reg_mcr(reg);
>>             u32 val;
>>
>> -            /*
>> -             * Skip reading the register if it's not really needed
>> -             */
>>             if (reg.masked)
>>                 val = entry->clr_bits << 16;
>> -            else if (entry->clr_bits + 1)
>> -                val = (reg.mcr ?
>> -                       xe_gt_mcr_unicast_read_any(gt, reg_mcr) :
>> -                       xe_mmio_read32(&gt->mmio, reg)) & (~entry-
>> >clr_bits);
>> -            else
>> +            else if (entry->clr_bits == ~0)
>>                 val = 0;
>> +            else
>> +                continue;
>>
>>             val |= entry->set_bits;
>>
>> @@ -239,6 +235,52 @@ static int emit_wa_job(struct xe_gt *gt, struct
>> xe_exec_queue *q)
>>         }
>>     }
>>
>> +    if (count_rmw) {
>> +        /* emit MI_MATH for each RMW reg */
>> +
>> +        xa_for_each(&sr->xa, idx, entry) {
>> +            if (entry->reg.masked || entry->clr_bits == ~0)
>> +                continue;
> 
> why can't we handle the normal writes here as well and avoid having some
> written from the CPU side and some from the GPU side?
> 

there were/are no writes here, we had reads only in case of the RMW
value that had to be programmed in LRI (previous approach)

and we have two loops since first covers all simple writes as all could
be programmed as single LRI command, while second loop emits separate
MATH commands per each RMW


  reply	other threads:[~2025-03-03 18:48 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-03 17:35 [PATCH 0/5] Use MI_MATH to apply RMW WA in LRC Michal Wajdeczko
2025-03-03 17:35 ` [PATCH 1/5] drm/xe: Add MI_LOAD_REGISTER_REG command definition Michal Wajdeczko
2025-03-03 21:18   ` Matt Roper
2025-03-03 17:35 ` [PATCH 2/5] drm/xe: Add MI_MATH and ALU instruction definitions Michal Wajdeczko
2025-03-03 21:50   ` Matt Roper
2025-03-04 16:23   ` [PATCH v2 " Michal Wajdeczko
2025-03-03 17:35 ` [PATCH 3/5] drm/xe: Avoid reading RMW registers in emit_wa_job Michal Wajdeczko
2025-03-03 18:06   ` Lucas De Marchi
2025-03-03 18:47     ` Michal Wajdeczko [this message]
2025-03-04 16:50       ` Lucas De Marchi
2025-03-03 22:06   ` Matt Roper
2025-03-03 17:35 ` [PATCH 4/5] drm/xe/vf: Stop applying save-restore MMIOs if VF Michal Wajdeczko
2025-03-03 18:09   ` Lucas De Marchi
2025-03-03 22:16     ` Matt Roper
2025-03-03 22:16   ` Matt Roper
2025-03-03 17:35 ` [PATCH 5/5] drm/xe/vf: Unblock xe_rtp_process_to_sr for VFs Michal Wajdeczko
2025-03-03 22:17   ` Matt Roper
2025-03-11 10:52   ` [PATCH v2 " Michal Wajdeczko
2025-03-03 17:44 ` ✓ CI.Patch_applied: success for Use MI_MATH to apply RMW WA in LRC Patchwork
2025-03-03 17:44 ` ✗ CI.checkpatch: warning " Patchwork
2025-03-03 17:46 ` ✓ CI.KUnit: success " Patchwork
2025-03-03 18:02 ` ✓ CI.Build: " Patchwork
2025-03-03 18:05 ` ✓ CI.Hooks: " Patchwork
2025-03-03 18:06 ` ✓ CI.checksparse: " Patchwork
2025-03-03 18:38 ` ✓ Xe.CI.BAT: " Patchwork
2025-03-03 20:12 ` ✗ Xe.CI.Full: failure " Patchwork
2025-03-04 17:27 ` ✓ CI.Patch_applied: success for Use MI_MATH to apply RMW WA in LRC (rev2) Patchwork
2025-03-04 17:27 ` ✗ CI.checkpatch: warning " Patchwork
2025-03-04 17:28 ` ✓ CI.KUnit: success " Patchwork
2025-03-04 17:45 ` ✓ CI.Build: " Patchwork
2025-03-04 17:47 ` ✓ CI.Hooks: " Patchwork
2025-03-04 17:48 ` ✓ CI.checksparse: " Patchwork
2025-03-05  5:43 ` ✗ Xe.CI.BAT: failure " Patchwork
2025-03-07 16:34   ` Michal Wajdeczko
2025-03-07 18:12 ` ✓ CI.Patch_applied: success for Use MI_MATH to apply RMW WA in LRC (rev3) Patchwork
2025-03-07 18:13 ` ✗ CI.checkpatch: warning " Patchwork
2025-03-07 18:14 ` ✓ CI.KUnit: success " Patchwork
2025-03-07 18:36 ` ✓ CI.Build: " Patchwork
2025-03-07 18:39 ` ✓ CI.Hooks: " Patchwork
2025-03-07 18:41 ` ✓ CI.checksparse: " Patchwork
2025-03-07 19:03 ` ✓ Xe.CI.BAT: " Patchwork
2025-03-08 20:46 ` ✗ Xe.CI.Full: failure " Patchwork
2025-03-10 16:31   ` Michal Wajdeczko
2025-03-11 12:55 ` ✓ CI.Patch_applied: success for Use MI_MATH to apply RMW WA in LRC (rev4) Patchwork
2025-03-11 12:55 ` ✗ CI.checkpatch: warning " Patchwork
2025-03-11 12:56 ` ✓ CI.KUnit: success " Patchwork
2025-03-11 13:13 ` ✓ CI.Build: " Patchwork
2025-03-11 13:15 ` ✓ CI.Hooks: " Patchwork
2025-03-11 13:17 ` ✓ CI.checksparse: " Patchwork
2025-03-11 13:37 ` ✓ Xe.CI.BAT: " Patchwork
2025-03-12  5:41 ` ✗ Xe.CI.Full: failure " Patchwork
2025-03-12 10:34   ` 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=64899758-d054-4f0c-a38f-8931473bada7@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=michal.winiarski@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