All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Ben Widawsky <ben@bwidawsk.net>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] on top of daniel
Date: Thu, 22 Sep 2011 09:39:21 +0200	[thread overview]
Message-ID: <20110922073921.GD2924@phenom.ffwll.local> (raw)
In-Reply-To: <1316656031-11239-3-git-send-email-ben@bwidawsk.net>

On Wed, Sep 21, 2011 at 06:47:11PM -0700, Ben Widawsky wrote:
> Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> ---
>  include/drm/i915_drm.h   |    7 +++++++
>  intel/intel_bufmgr_gem.c |   36 ++++++++++++++++++++++++++++++------
>  2 files changed, 37 insertions(+), 6 deletions(-)
> 
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index adc2392..4b62222 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -189,6 +189,7 @@ typedef struct _drm_i915_sarea {
>  #define DRM_I915_OVERLAY_PUT_IMAGE	0x27
>  #define DRM_I915_OVERLAY_ATTRS	0x28
>  #define DRM_I915_GEM_EXECBUFFER2	0x29
> +#define DRM_I915_GEM_GET_CACHE_TYPE	0x2a
>  
>  #define DRM_IOCTL_I915_INIT		DRM_IOW( DRM_COMMAND_BASE + DRM_I915_INIT, drm_i915_init_t)
>  #define DRM_IOCTL_I915_FLUSH		DRM_IO ( DRM_COMMAND_BASE + DRM_I915_FLUSH)
> @@ -230,6 +231,7 @@ typedef struct _drm_i915_sarea {
>  #define DRM_IOCTL_I915_GEM_MADVISE	DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_MADVISE, struct drm_i915_gem_madvise)
>  #define DRM_IOCTL_I915_OVERLAY_PUT_IMAGE	DRM_IOW(DRM_COMMAND_BASE + DRM_IOCTL_I915_OVERLAY_ATTRS, struct drm_intel_overlay_put_image)
>  #define DRM_IOCTL_I915_OVERLAY_ATTRS	DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
> +#define DRM_IOCTL_I915_GEM_GET_CACHE_TYPE	DRM_IOR  (DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHE_TYPE, struct drm_i915_gem_get_cache_type)
>  
>  /* Allow drivers to submit batchbuffers directly to hardware, relying
>   * on the security mechanisms provided by hardware.
> @@ -835,4 +837,9 @@ struct drm_intel_overlay_attrs {
>  	__u32 gamma5;
>  };
>  
> +struct drm_i915_gem_get_cache_type {
> +	__u32 handle;
> +	__u32 cache_level;
> +};
> +
>  #endif				/* _I915_DRM_H_ */
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index ff4b663..65a77d6 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -1032,6 +1032,30 @@ static int do_mmap_cpu(drm_intel_bufmgr_gem *bufmgr_gem,
>  	return 0;
>  }
>  
> +enum i915_cache_level {
> +	I915_CACHE_NONE,
> +	I915_CACHE_LLC,
> +	I915_CACHE_LLC_MLC, /* gen6+ */
> +};
> +
> +static int get_cache_type(drm_intel_bo *bo)
> +{
> +	struct drm_i915_gem_get_cache_type cache = {0, 0};
> +	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
> +	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
> +	int ret = 0;
> +
> +	cache.handle = bo_gem->gem_handle;
> +	ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_GET_CACHE_TYPE,
> +		       &cache);
> +
> +	/* This should maintain old behavior */
> +	if (ret)
> +		return 0;

Can you return I915_CACHE_NONE instead of this magic 0?

> +	return cache.cache_level;

Can we do

#define CACHE_LEVEL 0xff
	return cache.cache_leve & CACHE_LEVEL

instead so that we retain a few bits for flags (e.g. gfdt or whatever
other crazy stuff future hw might bring)? Alternatively, just add 64 bits
of pad to the ioctl struct.

> +}
> +
>  static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable)
>  {
>  	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
> @@ -1065,8 +1089,8 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int write_enable)
>  		    strerror(errno));
>  	}
>  
> -	/* TODO ask kernel if llc cached, in that case don't clear this */
> -	bo_gem->in_gtt_domain = 0;
> +	if (get_cache_type(bo) != I915_CACHE_LLC)
> +		bo_gem->in_gtt_domain = 0;
>  
>  	pthread_mutex_unlock(&bufmgr_gem->lock);
>  
> @@ -1335,14 +1359,14 @@ int drm_intel_gem_bo_map_nonblocking(drm_intel_bo *bo)
>  	drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
>  	drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
>  	struct drm_i915_gem_set_domain set_domain;
> -	int gpu_coherent_cpu_map;
> +	int gpu_coherent_cpu_map = 0;
>  	int ret;
>  
>  	pthread_mutex_lock(&bufmgr_gem->lock);
> -	assert(bo_gem->tiling_mode != I915_TILING_NONE);
> +	assert(bo_gem->tiling_mode == I915_TILING_NONE);

Oops, good catch ;-)

> -	/* TODO ask the kernel about this */
> -	gpu_coherent_cpu_map = 1;
> +	if (bufmgr_gem->gen >= 6)
> +		gpu_coherent_cpu_map = 1;
>  
>  	if (gpu_coherent_cpu_map) {
>  		ret = do_mmap_cpu(bufmgr_gem, bo_gem);
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2011-09-22  7:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-20  4:25 [PATCH 1/6] RFCish: write only mappings (aka non-blocking) Ben Widawsky
2011-09-20  4:25 ` [PATCH 1/6] drm/i915: object CPU flush interface Ben Widawsky
2011-09-20  4:25 ` [PATCH 2/6] drm/i915: write only object tracking Ben Widawsky
2011-09-20  4:25 ` [PATCH 3/6] drm/i915: Support write only mappings Ben Widawsky
2011-09-20  5:29   ` Keith Packard
2011-09-20  5:37     ` Ben Widawsky
2011-09-20  8:30   ` Chris Wilson
2011-09-20  4:25 ` [PATCH 4/6] intel: write only map support Ben Widawsky
2011-09-20  4:25 ` [PATCH 5/6] write-only mappings Ben Widawsky
2011-09-20  4:25 ` [PATCH 6/6] intel: use write only maps for MapRangeBuffer Ben Widawsky
2011-09-20 11:06 ` [PATCH 1/6] RFCish: write only mappings (aka non-blocking) Daniel Vetter
2011-09-20 17:17   ` Eric Anholt
2011-09-20 19:19     ` Daniel Vetter
2011-09-21  8:19       ` [PATCH] intel: non-blocking mmaps on the cheap Daniel Vetter
2011-09-21 18:11         ` Eric Anholt
2011-09-21 19:19           ` Daniel Vetter
2011-09-22  1:47             ` [PATCH cont'd] " Ben Widawsky
2011-09-22  1:47               ` [PATCH] drm/i915: ioctl to query a bo's cache level Ben Widawsky
2011-09-22  7:35                 ` Daniel Vetter
2011-09-22 15:36                   ` Ben Widawsky
2011-09-22 15:49                     ` Chris Wilson
2011-09-22  1:47               ` [PATCH] on top of daniel Ben Widawsky
2011-09-22  7:39                 ` Daniel Vetter [this message]
2011-09-22  7:33               ` [PATCH cont'd] intel: non-blocking mmaps on the cheap Daniel Vetter
2011-09-20 21:16   ` [PATCH 1/6] RFCish: write only mappings (aka non-blocking) Chris Wilson
2011-09-21  7:02     ` Daniel Vetter
2011-09-20 22:19   ` Ben Widawsky
2011-09-21  7:07     ` 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=20110922073921.GD2924@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=ben@bwidawsk.net \
    --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.