All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenneth Graunke <kenneth@whitecape.org>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Enable provoking vertex fix on Gen9 systems.
Date: Fri, 15 Jun 2018 22:07:19 -0700	[thread overview]
Message-ID: <3469060.PRjB1TPXYG@kirito> (raw)
In-Reply-To: <20180615190605.16238-1-chris@chris-wilson.co.uk>


[-- Attachment #1.1: Type: text/plain, Size: 4293 bytes --]

On Friday, June 15, 2018 12:06:05 PM PDT Chris Wilson wrote:
> From: Kenneth Graunke <kenneth@whitecape.org>
> 
> The SF and clipper units mishandle the provoking vertex in some cases,
> which can cause misrendering with shaders that use flat shaded inputs.
> 
> There are chicken bits in 3D_CHICKEN3 (for SF) and FF_SLICE_CHICKEN
> (for the clipper) that work around the issue.  These registers are
> unfortunately not part of the logical context (even the power context),
> and so we must reload them every time we start executing in a context.
> 
> Bugzilla: https://bugs.freedesktop.org/103047
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> 
> This is only being set for gen9 right now, do we need it for gen10+?

The 3D_CHICKEN3 bit is labeled as SKL and KBL.  The FF_SLICE_CHICKEN
bit is labeled as SKL, with no mention of KBL...but the Windows driver
appears to set both on all Gen 9.  It doesn't look like it sets them
on Gen 10, nor is documented to be necessary.  (I haven't brought up
a Cannonlake to test it, though...)

It looks like some of these registers are gone or reworked on Icelake,
so Gen9-only sounds good to me.

> Ken, I also need your s-o-b.

Oops, sorry...got out of the habit of adding that...

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>

Feel free to take authorship if you prefer - you've done much more work
on it than I have at this point. :)  Your call.  Thanks for fixing it
up and getting it landed, by the way!

It's a bummer that we have to do it here...but it seems like the only
place that it can realistically happen, with the power context issue.

It would be nice to Cc this to stable, but it seems like a lot of the
workaround code has changed a lot in the meantime, so not sure how well
it'd apply...

> An open question is how to record such w/a for easy checking from
> userspace. Though something like this might be better as part of an
> independent verification tool.
> -Chris
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  5 +++++
>  drivers/gpu/drm/i915/intel_lrc.c | 12 +++++++++++-
>  2 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index b8c0ebd50889..54ec7ab57ce8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2432,12 +2432,17 @@ enum i915_power_well_id {
>  #define _3D_CHICKEN	_MMIO(0x2084)
>  #define  _3D_CHICKEN_HIZ_PLANE_DISABLE_MSAA_4X_SNB	(1 << 10)
>  #define _3D_CHICKEN2	_MMIO(0x208c)
> +
> +#define FF_SLICE_CHICKEN	_MMIO(0x2088)
> +#define  FF_SLICE_CHICKEN_CL_PROVOKING_VERTEX_FIX	(1 << 1)
> +
>  /* Disables pipelining of read flushes past the SF-WIZ interface.
>   * Required on all Ironlake steppings according to the B-Spec, but the
>   * particular danger of not doing so is not specified.
>   */
>  # define _3D_CHICKEN2_WM_READ_PIPELINED			(1 << 14)
>  #define _3D_CHICKEN3	_MMIO(0x2090)
> +#define  _3D_CHICKEN_SF_PROVOKING_VERTEX_FIX		(1 << 12)
>  #define  _3D_CHICKEN_SF_DISABLE_OBJEND_CULL		(1 << 10)
>  #define  _3D_CHICKEN3_AA_LINE_QUALITY_FIX_ENABLE	(1 << 5)
>  #define  _3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL		(1 << 5)
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index 839cb1fc6a01..2b0ae552cc4e 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1575,11 +1575,21 @@ static u32 *gen9_init_indirectctx_bb(struct intel_engine_cs *engine, u32 *batch)
>  	/* WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt,glk */
>  	batch = gen8_emit_flush_coherentl3_wa(engine, batch);
>  
> +	*batch++ = MI_LOAD_REGISTER_IMM(3);
> +
>  	/* WaDisableGatherAtSetShaderCommonSlice:skl,bxt,kbl,glk */
> -	*batch++ = MI_LOAD_REGISTER_IMM(1);
>  	*batch++ = i915_mmio_reg_offset(COMMON_SLICE_CHICKEN2);
>  	*batch++ = _MASKED_BIT_DISABLE(
>  			GEN9_DISABLE_GATHER_AT_SET_SHADER_COMMON_SLICE);
> +
> +	/* BSpec: 11391 */
> +	*batch++ = i915_mmio_reg_offset(FF_SLICE_CHICKEN);
> +	*batch++ = _MASKED_BIT_ENABLE(FF_SLICE_CHICKEN_CL_PROVOKING_VERTEX_FIX);
> +
> +	/* BSpec: 11299 */
> +	*batch++ = i915_mmio_reg_offset(_3D_CHICKEN3);
> +	*batch++ = _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_PROVOKING_VERTEX_FIX);
> +
>  	*batch++ = MI_NOOP;
>  
>  	/* WaClearSlmSpaceAtContextSwitch:kbl */
> 


[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

  reply	other threads:[~2018-06-16  5:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-14 21:53 [PATCH] drm/i915: Enable provoking vertex fix on Gen9+ systems Kenneth Graunke
2018-06-14 22:37 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-06-14 22:53 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-06-15  7:16   ` Chris Wilson
2018-06-15  7:51     ` Chris Wilson
2018-06-15 14:52 ` Patchwork
2018-06-15 18:31 ` [PATCH] " Chris Wilson
2018-06-15 18:34 ` ✗ Fi.CI.BAT: failure for drm/i915: Enable provoking vertex fix on Gen9+ systems. (rev2) Patchwork
2018-06-15 19:06 ` [PATCH] drm/i915: Enable provoking vertex fix on Gen9 systems Chris Wilson
2018-06-16  5:07   ` Kenneth Graunke [this message]
2018-06-18  9:03   ` Joonas Lahtinen
2018-06-18  9:12     ` Chris Wilson
2018-06-15 20:09 ` ✓ Fi.CI.BAT: success for drm/i915: Enable provoking vertex fix on Gen9+ systems. (rev3) Patchwork
2018-06-16  9:35 ` ✓ Fi.CI.IGT: " Patchwork

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=3469060.PRjB1TPXYG@kirito \
    --to=kenneth@whitecape.org \
    --cc=chris@chris-wilson.co.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.