Re: [PATCH] drm/i915: FBC flush nuke for BDW

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Jul 31, 2014 at 12:07:44PM -0700, Rodrigo Vivi wrote:
> According to spec FBC on BDW and HSW are identical without any gaps.
> So let's copy the nuke and let FBC really start compressing stuff.
> 
> Without this patch we can verify with false color that nothing is being
> compressed. With the nuke in place and false color it is possible
> to see false color debugs.
> 
> v2: Fix rebase conflict.
> 
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 2908896..4ba3db1 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -406,6 +406,7 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
>  {
>  	u32 flags = 0;
>  	u32 scratch_addr = ring->scratch.gtt_offset + 2 * CACHELINE_BYTES;
> +	int ret;
>  
>  	flags |= PIPE_CONTROL_CS_STALL;
>  
> @@ -424,7 +425,14 @@ gen8_render_ring_flush(struct intel_engine_cs *ring,
>  		flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
>  	}
>  
> -	return gen8_emit_pipe_control(ring, flags, scratch_addr);
> +	ret = gen8_emit_pipe_control(ring, flags, scratch_addr);
> +	if (ret)
> +		return ret;
> +
> +	if (!invalidate_domains && flush_domains)
> +		return gen7_ring_fbc_flush(ring, FBC_REND_NUKE);
> +
> +	return 0;
>  }
>  
>  static void ring_write_tail(struct intel_engine_cs *ring,
> @@ -2065,7 +2073,7 @@ static int gen6_ring_flush(struct intel_engine_cs *ring,
>  	}
>  	intel_ring_advance(ring);
>  
> -	if (IS_GEN7(dev) && !invalidate && flush)
> +	if (INTEL_INFO(dev)->gen >= 7 && !invalidate && flush)
>  		return gen7_ring_fbc_flush(ring, FBC_REND_CACHE_CLEAN);

Apparently BDW has problems with LRIs to certain register offsets on
!RCS and this here would hit that. The suggested workaround is to emit
such LRIs only from RCS. Doing that would also involve tossing in a
semaphore, so it feels like something that ought to be handled
somewhere a bit higher up.

>  
>  	return 0;
> -- 
> 1.9.3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC