All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Use GGTT batchbuffer selector
Date: Wed, 10 Sep 2014 13:30:45 +0300	[thread overview]
Message-ID: <20140910103045.GQ4193@intel.com> (raw)
In-Reply-To: <1410341214-10116-1-git-send-email-chris@chris-wilson.co.uk>

On Wed, Sep 10, 2014 at 10:26:54AM +0100, Chris Wilson wrote:
> gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
> the security bit (i.e. only privileged batches were allowed to run from
> ggtt). From Haswell onwards, 

Not onwards unfortunately. BDW went back to the single bit approach.

> you are able to select the security bit
> separate from the address space - and we always requested to use ppgtt.
> This breaks the golden render state batch execution as that is only
> present in the global GTT and so we need to disable the use of the ppgtt
> selector bit, or else we hang immediately upon boot and thence after
> every GPU reset...
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 2 +-
>  drivers/gpu/drm/i915/i915_gem_render_state.c | 2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c      | 5 +++--
>  drivers/gpu/drm/i915/intel_ringbuffer.h      | 5 +++--
>  4 files changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 1a0611bb576b..8ff448dc8be4 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1260,7 +1260,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
>  		if (!file->is_master || !capable(CAP_SYS_ADMIN))
>  		    return -EPERM;
>  
> -		flags |= I915_DISPATCH_SECURE;
> +		flags |= I915_DISPATCH_SECURE | I915_DISPATCH_GGTT;
>  	}
>  	if (args->flags & I915_EXEC_IS_PINNED)
>  		flags |= I915_DISPATCH_PINNED;
> diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c b/drivers/gpu/drm/i915/i915_gem_render_state.c
> index a9a62d75aa57..a158d610720b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_render_state.c
> +++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
> @@ -165,7 +165,7 @@ int i915_gem_render_state_init(struct intel_engine_cs *ring)
>  	ret = ring->dispatch_execbuffer(ring,
>  					so.ggtt_offset,
>  					so.rodata->batch_items * 4,
> -					I915_DISPATCH_SECURE);
> +					I915_DISPATCH_GGTT);
>  	if (ret)
>  		goto out;
>  
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 109de2eeb9a8..d053819407da 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2174,7 +2174,7 @@ gen8_ring_dispatch_execbuffer(struct intel_engine_cs *ring,
>  			      u64 offset, u32 len,
>  			      unsigned flags)
>  {
> -	bool ppgtt = USES_PPGTT(ring->dev) && !(flags & I915_DISPATCH_SECURE);
> +	bool ppgtt = USES_PPGTT(ring->dev) && !(flags & I915_DISPATCH_GGTT);
>  	int ret;
>  
>  	ret = intel_ring_begin(ring, 4);
> @@ -2203,7 +2203,8 @@ hsw_ring_dispatch_execbuffer(struct intel_engine_cs *ring,
>  		return ret;
>  
>  	intel_ring_emit(ring,
> -			MI_BATCH_BUFFER_START | MI_BATCH_PPGTT_HSW |
> +			MI_BATCH_BUFFER_START |
> +			(flags & I915_DISPATCH_GGTT ? 0 : MI_BATCH_PPGTT_HSW) |
>  			(flags & I915_DISPATCH_SECURE ? 0 : MI_BATCH_NON_SECURE_HSW));

Do we actually want to make a distinction between GGTT and secure given
that HSW is the only one where it makes any difference? Why not just
set both GGGT and secure bits on HSW when I915_DISPATCH_SECURE is set?

>  	/* bit0-7 is the length on GEN6+ */
>  	intel_ring_emit(ring, offset);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 96479c89f4bd..755585a6fcc7 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -169,8 +169,9 @@ struct  intel_engine_cs {
>  	int		(*dispatch_execbuffer)(struct intel_engine_cs *ring,
>  					       u64 offset, u32 length,
>  					       unsigned flags);
> -#define I915_DISPATCH_SECURE 0x1
> -#define I915_DISPATCH_PINNED 0x2
> +#define I915_DISPATCH_GGTT	0x1
> +#define I915_DISPATCH_SECURE	0x2
> +#define I915_DISPATCH_PINNED	0x4
>  	void		(*cleanup)(struct intel_engine_cs *ring);
>  
>  	/* GEN8 signal/wait table - never trust comments!
> -- 
> 2.1.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

  parent reply	other threads:[~2014-09-10 10:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10  9:26 [PATCH] drm/i915: Use GGTT batchbuffer selector Chris Wilson
2014-09-10  9:46 ` Chris Wilson
2014-09-10 10:30 ` Ville Syrjälä [this message]
2014-09-10 10:50   ` Chris Wilson
2014-09-10 11:18   ` [PATCH] drm/i915: HSW always use GGTT selector for secure batches Chris Wilson
2014-09-10 11:21     ` Chris Wilson
2014-09-10 12:00       ` Ville Syrjälä
2014-09-10 12:16         ` Daniel Vetter

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=20140910103045.GQ4193@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --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.