public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Siluvery, Arun" <arun.siluvery@linux.intel.com>
To: Dave Gordon <david.s.gordon@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 6/6] drm/i915/gen8: Add WaRsRestoreWithPerCtxtBb workaround
Date: Fri, 12 Jun 2015 12:58:35 +0100	[thread overview]
Message-ID: <557AC96B.3040101@linux.intel.com> (raw)
In-Reply-To: <557733DA.7020106@intel.com>

On 09/06/2015 19:43, Dave Gordon wrote:
> On 05/06/15 14:57, Arun Siluvery wrote:
>> In Per context w/a batch buffer,
>> WaRsRestoreWithPerCtxtBb
>>
>> v2: This patches modifies definitions of MI_LOAD_REGISTER_MEM and
>> MI_LOAD_REGISTER_REG; Add GEN8 specific defines for these instructions
>> so as to not break any future users of existing definitions (Michel)
>>
>> Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com>
>> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
>> ---
>>   drivers/gpu/drm/i915/i915_reg.h  | 26 ++++++++++++++++++
>>   drivers/gpu/drm/i915/intel_lrc.c | 59 ++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 85 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>> index 33b0ff1..6928162 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
> [snip]
>>   #define MI_LOAD_REGISTER_MEM    MI_INSTR(0x29, 0)
>>   #define MI_LOAD_REGISTER_REG    MI_INSTR(0x2A, 0)
>> +#define MI_LOAD_REGISTER_MEM_GEN8 MI_INSTR(0x29, 2)
>> +#define   MI_LRM_USE_GLOBAL_GTT (1<<22)
>> +#define   MI_LRM_ASYNC_MODE_ENABLE (1<<21)
>> +#define MI_LOAD_REGISTER_REG_GEN8 MI_INSTR(0x2A, 1)
>
> Isn't the original definition of MI_LOAD_REGISTER_REG wrong anyway? It's
> a two-operand instruction, each of which is a one-word MMIO register
> address, hence always 3 words total. The length bias is 2, so the
> so-called 'flags' field must be 1. The original definition (where the
> second argument of the MI_INSTR macro is 0) shouldn't work.
>
> So just correct the original definition of MI_LOAD_REGISTER_REG; this
> isn't something that's actually changed on GEN8.
>
I did notice that the original instructions are odd but thought I might 
be wrong hence I created new ones to not disturb the original ones.
ok I will just correct original one and reuse it.

> While we're mentioning it, I think the above MI_LOAD_REGISTER_MEM is
> wrong too. The length should be 1 pre-GEN8, and 2 in GEN8+.
>
ok.
>>   #define MI_RS_STORE_DATA_IMM    MI_INSTR(0x2B, 0)
>>   #define MI_LOAD_URB_MEM         MI_INSTR(0x2C, 0)
>>   #define MI_STORE_URB_MEM        MI_INSTR(0x2D, 0)
>
> And these are wrong too! In fact all of these instructions have been
> added under a comment which says "Commands used only by the command
> parser". Looks like they were added as placeholders without the proper
> length fields, and then people have started using them as though they
> were complete definitions :(
>
> Time update them all, perhaps ...
these are not related to this patch, so it can be taken up as a 
different patch.
>
> [snip]
>
>> +	/*
>> +	 * BSpec says MI_LOAD_REGISTER_MEM, MI_LOAD_REGISTER_REG and
>> +	 * MI_BATCH_BUFFER_END instructions in this sequence need to be
>> +	 * in the same cacheline.
>> +	 */
>> +	while (((unsigned long) (cmd + index) % CACHELINE_BYTES) != 0)
>> +		cmd[index++] = MI_NOOP;
>> +
>> +	cmd[index++] = MI_LOAD_REGISTER_MEM_GEN8 |
>> +		MI_LRM_USE_GLOBAL_GTT |
>> +		MI_LRM_ASYNC_MODE_ENABLE;
>> +	cmd[index++] = INSTPM;
>> +	cmd[index++] = scratch_addr;
>> +	cmd[index++] = 0;
>> +
>> +	/*
>> +	 * BSpec says there should not be any commands programmed
>> +	 * between MI_LOAD_REGISTER_REG and MI_BATCH_BUFFER_END so
>> +	 * do not add any new commands
>> +	 */
>> +	cmd[index++] = MI_LOAD_REGISTER_REG_GEN8;
>> +	cmd[index++] = GEN8_RS_PREEMPT_STATUS;
>> +	cmd[index++] = GEN8_RS_PREEMPT_STATUS;
>> +
>>   	/* padding */
>>           while (index < end)
>>   		cmd[index++] = MI_NOOP;
>>
>
> Where's the MI_BATCH_BUFFER_END referred to in the comment?

MI_BATCH_BUFFER_END is just below while loop, it is in patch [v3 1/6].
Since the diff context is only few lines it didn't showup in the diff.

regards
Arun

>
> .Dave.
>
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-06-12 11:58 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-05 10:34 [PATCH v3 0/6] Add Per-context WA using WA batch buffers Arun Siluvery
2015-06-05 10:34 ` [PATCH v3 1/6] drm/i915/gen8: Add infrastructure to initialize " Arun Siluvery
2015-06-05 10:56   ` Chris Wilson
2015-06-05 11:24     ` Siluvery, Arun
2015-06-05 11:36       ` Chris Wilson
2015-06-05 11:56         ` Siluvery, Arun
2015-06-05 11:00   ` Chris Wilson
2015-06-15 15:22     ` Daniel Vetter
2015-06-15 15:23       ` Siluvery, Arun
2015-06-05 13:54   ` Arun Siluvery
2015-06-05 10:34 ` [PATCH v3 2/6] drm/i915/gen8: Re-order init pipe_control in lrc mode Arun Siluvery
2015-06-05 13:55   ` Arun Siluvery
2015-06-09 15:27   ` Dave Gordon
2015-06-09 15:34     ` Siluvery, Arun
2015-06-05 10:34 ` [PATCH v3 3/6] drm/i915/gen8: Add WaDisableCtxRestoreArbitration workaround Arun Siluvery
2015-06-05 13:56   ` Arun Siluvery
2015-06-05 10:34 ` [PATCH v3 4/6] drm/i915/gen8: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround Arun Siluvery
2015-06-05 13:56   ` Arun Siluvery
2015-06-05 14:48     ` Ville Syrjälä
2015-06-12 11:51       ` Siluvery, Arun
2015-06-09 17:06   ` Dave Gordon
2015-06-05 10:34 ` [PATCH v3 5/6] drm/i915/gen8: Add WaClearSlmSpaceAtContextSwitch workaround Arun Siluvery
2015-06-05 13:57   ` Arun Siluvery
2015-06-05 10:34 ` [PATCH v3 6/6] drm/i915/gen8: Add WaRsRestoreWithPerCtxtBb workaround Arun Siluvery
2015-06-05 13:57   ` Arun Siluvery
2015-06-09 18:43     ` Dave Gordon
2015-06-12 11:58       ` Siluvery, Arun [this message]
2015-06-12 17:03         ` Dave Gordon
2015-06-15 14:10           ` Siluvery, Arun
2015-06-15 17:29             ` Dave Gordon
2015-06-15 18:09               ` Siluvery, Arun
2015-06-15 15:27           ` Daniel Vetter
2015-06-06  8:20   ` shuang.he

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=557AC96B.3040101@linux.intel.com \
    --to=arun.siluvery@linux.intel.com \
    --cc=david.s.gordon@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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