intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH 24/45] drm/i915: Split GEM object type definition to its own header
Date: Fri, 26 Apr 2019 15:12:49 +0300	[thread overview]
Message-ID: <87r29prmm6.fsf@intel.com> (raw)
In-Reply-To: <20190425092004.9995-24-chris@chris-wilson.co.uk>

On Thu, 25 Apr 2019, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> For convenience in avoiding inline spaghetti, keep the type definition
> as a separate header.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
> ---
>  drivers/gpu/drm/i915/Makefile                 |   1 +
>  drivers/gpu/drm/i915/gem/Makefile             |   1 +
>  drivers/gpu/drm/i915/gem/Makefile.header-test |  16 +
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  | 285 +++++++++++++++++
>  drivers/gpu/drm/i915/gt/intel_engine_types.h  |   1 +
>  drivers/gpu/drm/i915/i915_drv.h               |   3 +-
>  drivers/gpu/drm/i915/i915_gem_batch_pool.h    |   3 +-
>  drivers/gpu/drm/i915/i915_gem_gtt.h           |   1 +
>  drivers/gpu/drm/i915/i915_gem_object.h        | 295 +-----------------
>  9 files changed, 312 insertions(+), 294 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gem/Makefile
>  create mode 100644 drivers/gpu/drm/i915/gem/Makefile.header-test
>  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_object_types.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 58643373495c..def781c9ea69 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -85,6 +85,7 @@ gt-$(CONFIG_DRM_I915_SELFTEST) += \
>  i915-y += $(gt-y)
>  
>  # GEM (Graphics Execution Management) code
> +obj-y += gem/

I think this warrants similar treatment as gt/. Posted standalone
instead of hidden in a series, explicit acks.

Provided the split makes sense to Joonas,

Acked-by: Jani Nikula <jani.nikula@intel.com>


>  i915-y += \
>  	  i915_active.o \
>  	  i915_cmd_parser.o \
> diff --git a/drivers/gpu/drm/i915/gem/Makefile b/drivers/gpu/drm/i915/gem/Makefile
> new file mode 100644
> index 000000000000..07e7b8b840ea
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gem/Makefile
> @@ -0,0 +1 @@
> +include $(src)/Makefile.header-test # Extra header tests
> diff --git a/drivers/gpu/drm/i915/gem/Makefile.header-test b/drivers/gpu/drm/i915/gem/Makefile.header-test
> new file mode 100644
> index 000000000000..61e06cbb4b32
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gem/Makefile.header-test
> @@ -0,0 +1,16 @@
> +# SPDX-License-Identifier: MIT
> +# Copyright © 2019 Intel Corporation
> +
> +# Test the headers are compilable as standalone units
> +header_test := $(notdir $(wildcard $(src)/*.h))
> +
> +quiet_cmd_header_test = HDRTEST $@
> +      cmd_header_test = echo "\#include \"$(<F)\"" > $@
> +
> +header_test_%.c: %.h
> +	$(call cmd,header_test)
> +
> +extra-$(CONFIG_DRM_I915_WERROR) += \
> +	$(foreach h,$(header_test),$(patsubst %.h,header_test_%.o,$(h)))
> +
> +clean-files += $(foreach h,$(header_test),$(patsubst %.h,header_test_%.c,$(h)))
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> new file mode 100644
> index 000000000000..e4b50944f553
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -0,0 +1,285 @@
> +/*
> + * SPDX-License-Identifier: MIT
> + *
> + * Copyright © 2016 Intel Corporation
> + */
> +
> +#ifndef __I915_GEM_OBJECT_TYPES_H__
> +#define __I915_GEM_OBJECT_TYPES_H__
> +
> +#include <linux/reservation.h>
> +
> +#include <drm/drm_gem.h>
> +
> +#include "../i915_active.h"
> +#include "../i915_selftest.h"
> +
> +struct drm_i915_gem_object;
> +
> +/*
> + * struct i915_lut_handle tracks the fast lookups from handle to vma used
> + * for execbuf. Although we use a radixtree for that mapping, in order to
> + * remove them as the object or context is closed, we need a secondary list
> + * and a translation entry (i915_lut_handle).
> + */
> +struct i915_lut_handle {
> +	struct list_head obj_link;
> +	struct list_head ctx_link;
> +	struct i915_gem_context *ctx;
> +	u32 handle;
> +};
> +
> +struct drm_i915_gem_object_ops {
> +	unsigned int flags;
> +#define I915_GEM_OBJECT_HAS_STRUCT_PAGE	BIT(0)
> +#define I915_GEM_OBJECT_IS_SHRINKABLE	BIT(1)
> +#define I915_GEM_OBJECT_IS_PROXY	BIT(2)
> +#define I915_GEM_OBJECT_ASYNC_CANCEL	BIT(3)
> +
> +	/* Interface between the GEM object and its backing storage.
> +	 * get_pages() is called once prior to the use of the associated set
> +	 * of pages before to binding them into the GTT, and put_pages() is
> +	 * called after we no longer need them. As we expect there to be
> +	 * associated cost with migrating pages between the backing storage
> +	 * and making them available for the GPU (e.g. clflush), we may hold
> +	 * onto the pages after they are no longer referenced by the GPU
> +	 * in case they may be used again shortly (for example migrating the
> +	 * pages to a different memory domain within the GTT). put_pages()
> +	 * will therefore most likely be called when the object itself is
> +	 * being released or under memory pressure (where we attempt to
> +	 * reap pages for the shrinker).
> +	 */
> +	int (*get_pages)(struct drm_i915_gem_object *obj);
> +	void (*put_pages)(struct drm_i915_gem_object *obj,
> +			  struct sg_table *pages);
> +
> +	int (*pwrite)(struct drm_i915_gem_object *obj,
> +		      const struct drm_i915_gem_pwrite *arg);
> +
> +	int (*dmabuf_export)(struct drm_i915_gem_object *obj);
> +	void (*release)(struct drm_i915_gem_object *obj);
> +};
> +
> +struct drm_i915_gem_object {
> +	struct drm_gem_object base;
> +
> +	const struct drm_i915_gem_object_ops *ops;
> +
> +	struct {
> +		/**
> +		 * @vma.lock: protect the list/tree of vmas
> +		 */
> +		spinlock_t lock;
> +
> +		/**
> +		 * @vma.list: List of VMAs backed by this object
> +		 *
> +		 * The VMA on this list are ordered by type, all GGTT vma are
> +		 * placed at the head and all ppGTT vma are placed at the tail.
> +		 * The different types of GGTT vma are unordered between
> +		 * themselves, use the @vma.tree (which has a defined order
> +		 * between all VMA) to quickly find an exact match.
> +		 */
> +		struct list_head list;
> +
> +		/**
> +		 * @vma.tree: Ordered tree of VMAs backed by this object
> +		 *
> +		 * All VMA created for this object are placed in the @vma.tree
> +		 * for fast retrieval via a binary search in
> +		 * i915_vma_instance(). They are also added to @vma.list for
> +		 * easy iteration.
> +		 */
> +		struct rb_root tree;
> +	} vma;
> +
> +	/**
> +	 * @lut_list: List of vma lookup entries in use for this object.
> +	 *
> +	 * If this object is closed, we need to remove all of its VMA from
> +	 * the fast lookup index in associated contexts; @lut_list provides
> +	 * this translation from object to context->handles_vma.
> +	 */
> +	struct list_head lut_list;
> +
> +	/** Stolen memory for this object, instead of being backed by shmem. */
> +	struct drm_mm_node *stolen;
> +	union {
> +		struct rcu_head rcu;
> +		struct llist_node freed;
> +	};
> +
> +	/**
> +	 * Whether the object is currently in the GGTT mmap.
> +	 */
> +	unsigned int userfault_count;
> +	struct list_head userfault_link;
> +
> +	struct list_head batch_pool_link;
> +	I915_SELFTEST_DECLARE(struct list_head st_link);
> +
> +	unsigned long flags;
> +
> +	/**
> +	 * Have we taken a reference for the object for incomplete GPU
> +	 * activity?
> +	 */
> +#define I915_BO_ACTIVE_REF 0
> +
> +	/*
> +	 * Is the object to be mapped as read-only to the GPU
> +	 * Only honoured if hardware has relevant pte bit
> +	 */
> +	unsigned int cache_level:3;
> +	unsigned int cache_coherent:2;
> +#define I915_BO_CACHE_COHERENT_FOR_READ BIT(0)
> +#define I915_BO_CACHE_COHERENT_FOR_WRITE BIT(1)
> +	unsigned int cache_dirty:1;
> +
> +	/**
> +	 * @read_domains: Read memory domains.
> +	 *
> +	 * These monitor which caches contain read/write data related to the
> +	 * object. When transitioning from one set of domains to another,
> +	 * the driver is called to ensure that caches are suitably flushed and
> +	 * invalidated.
> +	 */
> +	u16 read_domains;
> +
> +	/**
> +	 * @write_domain: Corresponding unique write memory domain.
> +	 */
> +	u16 write_domain;
> +
> +	atomic_t frontbuffer_bits;
> +	unsigned int frontbuffer_ggtt_origin; /* write once */
> +	struct i915_active_request frontbuffer_write;
> +
> +	/** Current tiling stride for the object, if it's tiled. */
> +	unsigned int tiling_and_stride;
> +#define FENCE_MINIMUM_STRIDE 128 /* See i915_tiling_ok() */
> +#define TILING_MASK (FENCE_MINIMUM_STRIDE - 1)
> +#define STRIDE_MASK (~TILING_MASK)
> +
> +	/** Count of VMA actually bound by this object */
> +	unsigned int bind_count;
> +	unsigned int active_count;
> +	/** Count of how many global VMA are currently pinned for use by HW */
> +	unsigned int pin_global;
> +
> +	struct {
> +		struct mutex lock; /* protects the pages and their use */
> +		atomic_t pages_pin_count;
> +
> +		struct sg_table *pages;
> +		void *mapping;
> +
> +		/* TODO: whack some of this into the error state */
> +		struct i915_page_sizes {
> +			/**
> +			 * The sg mask of the pages sg_table. i.e the mask of
> +			 * of the lengths for each sg entry.
> +			 */
> +			unsigned int phys;
> +
> +			/**
> +			 * The gtt page sizes we are allowed to use given the
> +			 * sg mask and the supported page sizes. This will
> +			 * express the smallest unit we can use for the whole
> +			 * object, as well as the larger sizes we may be able
> +			 * to use opportunistically.
> +			 */
> +			unsigned int sg;
> +
> +			/**
> +			 * The actual gtt page size usage. Since we can have
> +			 * multiple vma associated with this object we need to
> +			 * prevent any trampling of state, hence a copy of this
> +			 * struct also lives in each vma, therefore the gtt
> +			 * value here should only be read/write through the vma.
> +			 */
> +			unsigned int gtt;
> +		} page_sizes;
> +
> +		I915_SELFTEST_DECLARE(unsigned int page_mask);
> +
> +		struct i915_gem_object_page_iter {
> +			struct scatterlist *sg_pos;
> +			unsigned int sg_idx; /* in pages, but 32bit eek! */
> +
> +			struct radix_tree_root radix;
> +			struct mutex lock; /* protects this cache */
> +		} get_page;
> +
> +		/**
> +		 * Element within i915->mm.unbound_list or i915->mm.bound_list,
> +		 * locked by i915->mm.obj_lock.
> +		 */
> +		struct list_head link;
> +
> +		/**
> +		 * Advice: are the backing pages purgeable?
> +		 */
> +		unsigned int madv:2;
> +
> +		/**
> +		 * This is set if the object has been written to since the
> +		 * pages were last acquired.
> +		 */
> +		bool dirty:1;
> +
> +		/**
> +		 * This is set if the object has been pinned due to unknown
> +		 * swizzling.
> +		 */
> +		bool quirked:1;
> +	} mm;
> +
> +	/** Breadcrumb of last rendering to the buffer.
> +	 * There can only be one writer, but we allow for multiple readers.
> +	 * If there is a writer that necessarily implies that all other
> +	 * read requests are complete - but we may only be lazily clearing
> +	 * the read requests. A read request is naturally the most recent
> +	 * request on a ring, so we may have two different write and read
> +	 * requests on one ring where the write request is older than the
> +	 * read request. This allows for the CPU to read from an active
> +	 * buffer by only waiting for the write to complete.
> +	 */
> +	struct reservation_object *resv;
> +
> +	/** References from framebuffers, locks out tiling changes. */
> +	unsigned int framebuffer_references;
> +
> +	/** Record of address bit 17 of each page at last unbind. */
> +	unsigned long *bit_17;
> +
> +	union {
> +		struct i915_gem_userptr {
> +			uintptr_t ptr;
> +
> +			struct i915_mm_struct *mm;
> +			struct i915_mmu_object *mmu_object;
> +			struct work_struct *work;
> +		} userptr;
> +
> +		unsigned long scratch;
> +
> +		void *gvt_info;
> +	};
> +
> +	/** for phys allocated objects */
> +	struct drm_dma_handle *phys_handle;
> +
> +	struct reservation_object __builtin_resv;
> +};
> +
> +static inline struct drm_i915_gem_object *
> +to_intel_bo(struct drm_gem_object *gem)
> +{
> +	/* Assert that to_intel_bo(NULL) == NULL */
> +	BUILD_BUG_ON(offsetof(struct drm_i915_gem_object, base));
> +
> +	return container_of(gem, struct drm_i915_gem_object, base);
> +}
> +
> +#endif
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index ca8d95a5708d..ae73c6596d08 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -29,6 +29,7 @@
>  #define I915_CMD_HASH_ORDER 9
>  
>  struct dma_fence;
> +struct drm_i915_gem_object;
>  struct drm_i915_reg_table;
>  struct i915_gem_context;
>  struct i915_request;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5ca4df9a7428..0cf87495e11b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -80,7 +80,6 @@
>  #include "i915_gem.h"
>  #include "i915_gem_context.h"
>  #include "i915_gem_fence_reg.h"
> -#include "i915_gem_object.h"
>  #include "i915_gem_gtt.h"
>  #include "i915_gpu_error.h"
>  #include "i915_request.h"
> @@ -135,6 +134,8 @@ bool i915_error_injected(void);
>  	__i915_printk(i915, i915_error_injected() ? KERN_DEBUG : KERN_ERR, \
>  		      fmt, ##__VA_ARGS__)
>  
> +struct drm_i915_gem_object;
> +
>  enum hpd_pin {
>  	HPD_NONE = 0,
>  	HPD_TV = HPD_NONE,     /* TV is known to be unreliable */
> diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.h b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
> index 56947daaaf65..feeeeeaa54d8 100644
> --- a/drivers/gpu/drm/i915/i915_gem_batch_pool.h
> +++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
> @@ -9,6 +9,7 @@
>  
>  #include <linux/types.h>
>  
> +struct drm_i915_gem_object;
>  struct intel_engine_cs;
>  
>  struct i915_gem_batch_pool {
> @@ -19,7 +20,7 @@ struct i915_gem_batch_pool {
>  void i915_gem_batch_pool_init(struct i915_gem_batch_pool *pool,
>  			      struct intel_engine_cs *engine);
>  void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool);
> -struct drm_i915_gem_object*
> +struct drm_i915_gem_object *
>  i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool, size_t size);
>  
>  #endif /* I915_GEM_BATCH_POOL_H */
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 2fafa04c45ec..593079f30fbe 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -61,6 +61,7 @@
>  
>  struct drm_i915_file_private;
>  struct drm_i915_fence_reg;
> +struct drm_i915_gem_object;
>  struct i915_vma;
>  
>  typedef u32 gen6_pte_t;
> diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h
> index ca93a40c0c87..3666b0c5f6ca 100644
> --- a/drivers/gpu/drm/i915/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> @@ -1,308 +1,19 @@
>  /*
> - * Copyright © 2016 Intel Corporation
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the next
> - * paragraph) shall be included in all copies or substantial portions of the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> - * IN THE SOFTWARE.
> + * SPDX-License-Identifier: MIT
>   *
> + * Copyright © 2016 Intel Corporation
>   */
>  
>  #ifndef __I915_GEM_OBJECT_H__
>  #define __I915_GEM_OBJECT_H__
>  
> -#include <linux/reservation.h>
> -
> -#include <drm/drm_vma_manager.h>
>  #include <drm/drm_gem.h>
>  #include <drm/drm_file.h>
>  #include <drm/drm_device.h>
>  
>  #include <drm/i915_drm.h>
>  
> -#include "i915_request.h"
> -#include "i915_selftest.h"
> -
> -struct drm_i915_gem_object;
> -
> -/*
> - * struct i915_lut_handle tracks the fast lookups from handle to vma used
> - * for execbuf. Although we use a radixtree for that mapping, in order to
> - * remove them as the object or context is closed, we need a secondary list
> - * and a translation entry (i915_lut_handle).
> - */
> -struct i915_lut_handle {
> -	struct list_head obj_link;
> -	struct list_head ctx_link;
> -	struct i915_gem_context *ctx;
> -	u32 handle;
> -};
> -
> -struct drm_i915_gem_object_ops {
> -	unsigned int flags;
> -#define I915_GEM_OBJECT_HAS_STRUCT_PAGE	BIT(0)
> -#define I915_GEM_OBJECT_IS_SHRINKABLE	BIT(1)
> -#define I915_GEM_OBJECT_IS_PROXY	BIT(2)
> -#define I915_GEM_OBJECT_ASYNC_CANCEL	BIT(3)
> -
> -	/* Interface between the GEM object and its backing storage.
> -	 * get_pages() is called once prior to the use of the associated set
> -	 * of pages before to binding them into the GTT, and put_pages() is
> -	 * called after we no longer need them. As we expect there to be
> -	 * associated cost with migrating pages between the backing storage
> -	 * and making them available for the GPU (e.g. clflush), we may hold
> -	 * onto the pages after they are no longer referenced by the GPU
> -	 * in case they may be used again shortly (for example migrating the
> -	 * pages to a different memory domain within the GTT). put_pages()
> -	 * will therefore most likely be called when the object itself is
> -	 * being released or under memory pressure (where we attempt to
> -	 * reap pages for the shrinker).
> -	 */
> -	int (*get_pages)(struct drm_i915_gem_object *);
> -	void (*put_pages)(struct drm_i915_gem_object *, struct sg_table *);
> -
> -	int (*pwrite)(struct drm_i915_gem_object *,
> -		      const struct drm_i915_gem_pwrite *);
> -
> -	int (*dmabuf_export)(struct drm_i915_gem_object *);
> -	void (*release)(struct drm_i915_gem_object *);
> -};
> -
> -struct drm_i915_gem_object {
> -	struct drm_gem_object base;
> -
> -	const struct drm_i915_gem_object_ops *ops;
> -
> -	struct {
> -		/**
> -		 * @vma.lock: protect the list/tree of vmas
> -		 */
> -		spinlock_t lock;
> -
> -		/**
> -		 * @vma.list: List of VMAs backed by this object
> -		 *
> -		 * The VMA on this list are ordered by type, all GGTT vma are
> -		 * placed at the head and all ppGTT vma are placed at the tail.
> -		 * The different types of GGTT vma are unordered between
> -		 * themselves, use the @vma.tree (which has a defined order
> -		 * between all VMA) to quickly find an exact match.
> -		 */
> -		struct list_head list;
> -
> -		/**
> -		 * @vma.tree: Ordered tree of VMAs backed by this object
> -		 *
> -		 * All VMA created for this object are placed in the @vma.tree
> -		 * for fast retrieval via a binary search in
> -		 * i915_vma_instance(). They are also added to @vma.list for
> -		 * easy iteration.
> -		 */
> -		struct rb_root tree;
> -	} vma;
> -
> -	/**
> -	 * @lut_list: List of vma lookup entries in use for this object.
> -	 *
> -	 * If this object is closed, we need to remove all of its VMA from
> -	 * the fast lookup index in associated contexts; @lut_list provides
> -	 * this translation from object to context->handles_vma.
> -	 */
> -	struct list_head lut_list;
> -
> -	/** Stolen memory for this object, instead of being backed by shmem. */
> -	struct drm_mm_node *stolen;
> -	union {
> -		struct rcu_head rcu;
> -		struct llist_node freed;
> -	};
> -
> -	/**
> -	 * Whether the object is currently in the GGTT mmap.
> -	 */
> -	unsigned int userfault_count;
> -	struct list_head userfault_link;
> -
> -	struct list_head batch_pool_link;
> -	I915_SELFTEST_DECLARE(struct list_head st_link);
> -
> -	unsigned long flags;
> -
> -	/**
> -	 * Have we taken a reference for the object for incomplete GPU
> -	 * activity?
> -	 */
> -#define I915_BO_ACTIVE_REF 0
> -
> -	/*
> -	 * Is the object to be mapped as read-only to the GPU
> -	 * Only honoured if hardware has relevant pte bit
> -	 */
> -	unsigned int cache_level:3;
> -	unsigned int cache_coherent:2;
> -#define I915_BO_CACHE_COHERENT_FOR_READ BIT(0)
> -#define I915_BO_CACHE_COHERENT_FOR_WRITE BIT(1)
> -	unsigned int cache_dirty:1;
> -
> -	/**
> -	 * @read_domains: Read memory domains.
> -	 *
> -	 * These monitor which caches contain read/write data related to the
> -	 * object. When transitioning from one set of domains to another,
> -	 * the driver is called to ensure that caches are suitably flushed and
> -	 * invalidated.
> -	 */
> -	u16 read_domains;
> -
> -	/**
> -	 * @write_domain: Corresponding unique write memory domain.
> -	 */
> -	u16 write_domain;
> -
> -	atomic_t frontbuffer_bits;
> -	unsigned int frontbuffer_ggtt_origin; /* write once */
> -	struct i915_active_request frontbuffer_write;
> -
> -	/** Current tiling stride for the object, if it's tiled. */
> -	unsigned int tiling_and_stride;
> -#define FENCE_MINIMUM_STRIDE 128 /* See i915_tiling_ok() */
> -#define TILING_MASK (FENCE_MINIMUM_STRIDE-1)
> -#define STRIDE_MASK (~TILING_MASK)
> -
> -	/** Count of VMA actually bound by this object */
> -	unsigned int bind_count;
> -	unsigned int active_count;
> -	/** Count of how many global VMA are currently pinned for use by HW */
> -	unsigned int pin_global;
> -
> -	struct {
> -		struct mutex lock; /* protects the pages and their use */
> -		atomic_t pages_pin_count;
> -
> -		struct sg_table *pages;
> -		void *mapping;
> -
> -		/* TODO: whack some of this into the error state */
> -		struct i915_page_sizes {
> -			/**
> -			 * The sg mask of the pages sg_table. i.e the mask of
> -			 * of the lengths for each sg entry.
> -			 */
> -			unsigned int phys;
> -
> -			/**
> -			 * The gtt page sizes we are allowed to use given the
> -			 * sg mask and the supported page sizes. This will
> -			 * express the smallest unit we can use for the whole
> -			 * object, as well as the larger sizes we may be able
> -			 * to use opportunistically.
> -			 */
> -			unsigned int sg;
> -
> -			/**
> -			 * The actual gtt page size usage. Since we can have
> -			 * multiple vma associated with this object we need to
> -			 * prevent any trampling of state, hence a copy of this
> -			 * struct also lives in each vma, therefore the gtt
> -			 * value here should only be read/write through the vma.
> -			 */
> -			unsigned int gtt;
> -		} page_sizes;
> -
> -		I915_SELFTEST_DECLARE(unsigned int page_mask);
> -
> -		struct i915_gem_object_page_iter {
> -			struct scatterlist *sg_pos;
> -			unsigned int sg_idx; /* in pages, but 32bit eek! */
> -
> -			struct radix_tree_root radix;
> -			struct mutex lock; /* protects this cache */
> -		} get_page;
> -
> -		/**
> -		 * Element within i915->mm.unbound_list or i915->mm.bound_list,
> -		 * locked by i915->mm.obj_lock.
> -		 */
> -		struct list_head link;
> -
> -		/**
> -		 * Advice: are the backing pages purgeable?
> -		 */
> -		unsigned int madv:2;
> -
> -		/**
> -		 * This is set if the object has been written to since the
> -		 * pages were last acquired.
> -		 */
> -		bool dirty:1;
> -
> -		/**
> -		 * This is set if the object has been pinned due to unknown
> -		 * swizzling.
> -		 */
> -		bool quirked:1;
> -	} mm;
> -
> -	/** Breadcrumb of last rendering to the buffer.
> -	 * There can only be one writer, but we allow for multiple readers.
> -	 * If there is a writer that necessarily implies that all other
> -	 * read requests are complete - but we may only be lazily clearing
> -	 * the read requests. A read request is naturally the most recent
> -	 * request on a ring, so we may have two different write and read
> -	 * requests on one ring where the write request is older than the
> -	 * read request. This allows for the CPU to read from an active
> -	 * buffer by only waiting for the write to complete.
> -	 */
> -	struct reservation_object *resv;
> -
> -	/** References from framebuffers, locks out tiling changes. */
> -	unsigned int framebuffer_references;
> -
> -	/** Record of address bit 17 of each page at last unbind. */
> -	unsigned long *bit_17;
> -
> -	union {
> -		struct i915_gem_userptr {
> -			uintptr_t ptr;
> -
> -			struct i915_mm_struct *mm;
> -			struct i915_mmu_object *mmu_object;
> -			struct work_struct *work;
> -		} userptr;
> -
> -		unsigned long scratch;
> -
> -		void *gvt_info;
> -	};
> -
> -	/** for phys allocated objects */
> -	struct drm_dma_handle *phys_handle;
> -
> -	struct reservation_object __builtin_resv;
> -};
> -
> -static inline struct drm_i915_gem_object *
> -to_intel_bo(struct drm_gem_object *gem)
> -{
> -	/* Assert that to_intel_bo(NULL) == NULL */
> -	BUILD_BUG_ON(offsetof(struct drm_i915_gem_object, base));
> -
> -	return container_of(gem, struct drm_i915_gem_object, base);
> -}
> +#include "gem/i915_gem_object_types.h"
>  
>  struct drm_i915_gem_object *i915_gem_object_alloc(void);
>  void i915_gem_object_free(struct drm_i915_gem_object *obj);

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-04-26 12:10 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25  9:19 [PATCH 01/45] drm/i915: Seal races between async GPU cancellation, retirement and signaling Chris Wilson
2019-04-25  9:19 ` [PATCH 02/45] drm/i915/gvt: Pin the per-engine GVT shadow contexts Chris Wilson
2019-04-25  9:19 ` [PATCH 03/45] drm/i915: Export intel_context_instance() Chris Wilson
2019-04-25  9:19 ` [PATCH 04/45] drm/i915/selftests: Use the real kernel context for sseu isolation tests Chris Wilson
2019-04-25  9:19 ` [PATCH 05/45] drm/i915/selftests: Pass around intel_context for sseu Chris Wilson
2019-04-25  9:19 ` [PATCH 06/45] drm/i915: Pass intel_context to intel_context_pin_lock() Chris Wilson
2019-04-25  9:19 ` [PATCH 07/45] drm/i915: Split engine setup/init into two phases Chris Wilson
2019-04-25  9:19 ` [PATCH 08/45] drm/i915: Switch back to an array of logical per-engine HW contexts Chris Wilson
2019-04-25  9:19 ` [PATCH 09/45] drm/i915: Remove intel_context.active_link Chris Wilson
2019-04-25  9:19 ` [PATCH 10/45] drm/i915: Move i915_request_alloc into selftests/ Chris Wilson
2019-04-25  9:19 ` [PATCH 11/45] drm/i915/execlists: Flush the tasklet on parking Chris Wilson
2019-04-25  9:19 ` [PATCH 12/45] drm/i915: Move the engine->destroy() vfunc onto the engine Chris Wilson
2019-04-25 11:01   ` Tvrtko Ursulin
2019-04-25 11:24     ` Chris Wilson
2019-04-25 11:29     ` [PATCH v2] " Chris Wilson
2019-04-25 11:46       ` Tvrtko Ursulin
2019-04-25  9:19 ` [PATCH 13/45] drm/i915: Convert inconsistent static engine tables into an init error Chris Wilson
2019-04-25  9:19 ` [PATCH 14/45] drm/i915: Make engine_mask & num_engines static Chris Wilson
2019-04-25  9:30   ` Jani Nikula
2019-04-25 10:20   ` Tvrtko Ursulin
2019-04-25 10:30     ` Chris Wilson
2019-04-25 10:43       ` Tvrtko Ursulin
2019-04-25  9:19 ` [PATCH 15/45] drm/i915: Restore control over ppgtt for context creation ABI Chris Wilson
2019-04-25  9:19 ` [PATCH 16/45] drm/i915: Allow a context to define its set of engines Chris Wilson
2019-04-25  9:19 ` [PATCH 17/45] drm/i915: Re-expose SINGLE_TIMELINE flags for context creation Chris Wilson
2019-04-25  9:19 ` [PATCH 18/45] drm/i915: Allow userspace to clone contexts on creation Chris Wilson
2019-04-25  9:19 ` [PATCH 19/45] drm/i915: Load balancing across a virtual engine Chris Wilson
2019-04-25 12:14   ` Tvrtko Ursulin
2019-04-25 12:23     ` Chris Wilson
2019-04-29 13:43   ` Tvrtko Ursulin
2019-04-25  9:19 ` [PATCH 20/45] drm/i915: Apply an execution_mask to the virtual_engine Chris Wilson
2019-04-29 14:12   ` Tvrtko Ursulin
2019-05-07 16:59     ` Chris Wilson
2019-05-08  8:48       ` Tvrtko Ursulin
2019-04-25  9:19 ` [PATCH 21/45] drm/i915: Extend execution fence to support a callback Chris Wilson
2019-04-25  9:19 ` [PATCH 22/45] drm/i915/execlists: Virtual engine bonding Chris Wilson
2019-04-29 15:58   ` Tvrtko Ursulin
2019-04-25  9:19 ` [PATCH 23/45] drm/i915: Allow specification of parallel execbuf Chris Wilson
2019-04-25  9:19 ` [PATCH 24/45] drm/i915: Split GEM object type definition to its own header Chris Wilson
2019-04-26 12:12   ` Jani Nikula [this message]
2019-04-29  9:36     ` Joonas Lahtinen
2019-04-29 17:52       ` Rodrigo Vivi
2019-04-25  9:19 ` [PATCH 25/45] drm/i915: Pull GEM ioctls interface to its own file Chris Wilson
2019-04-25  9:19 ` [PATCH 26/45] drm/i915: Move object->pages API to i915_gem_object.[ch] Chris Wilson
2019-04-25  9:19 ` [PATCH 27/45] drm/i915: Move shmem object setup to its own file Chris Wilson
2019-04-25  9:19 ` [PATCH 28/45] drm/i915: Move phys objects " Chris Wilson
2019-04-25  9:19 ` [PATCH 29/45] drm/i915: Move mmap and friends " Chris Wilson
2019-04-25  9:19 ` [PATCH 30/45] drm/i915: Move GEM domain management " Chris Wilson
2019-04-25  9:19 ` [PATCH 31/45] drm/i915: Move more GEM objects under gem/ Chris Wilson
2019-04-25  9:19 ` [PATCH 32/45] drm/i915: Pull scatterlist utils out of i915_gem.h Chris Wilson
2019-04-25  9:19 ` [PATCH 33/45] lockdep: Swap storage for pin_count and refereneces Chris Wilson
2019-04-25  9:19 ` [PATCH 34/45] drm/i915: Move GEM object domain management from struct_mutex to local Chris Wilson
2019-04-25  9:19 ` [PATCH 35/45] drm/i915: Move GEM object waiting to its own file Chris Wilson
2019-04-25  9:19 ` [PATCH 36/45] drm/i915: Move GEM object busy checking " Chris Wilson
2019-04-25  9:19 ` [PATCH 37/45] drm/i915: Move GEM client throttling " Chris Wilson
2019-04-25  9:19 ` [PATCH 38/45] drm/i915: Drop the deferred active reference Chris Wilson
2019-05-01 10:34   ` Matthew Auld
2019-04-25  9:19 ` [PATCH 39/45] drm/i915: Move object close under its own lock Chris Wilson
2019-04-25  9:19 ` [PATCH 40/45] drm/i915: Rename intel_context.active to .inflight Chris Wilson
2019-04-25  9:20 ` [PATCH 41/45] drm/i915: Keep contexts pinned until after the next kernel context switch Chris Wilson
2019-04-25  9:20 ` [PATCH 42/45] drm/i915: Stop retiring along engine Chris Wilson
2019-04-25  9:20 ` [PATCH 43/45] drm/i915: Replace engine->timeline with a plain list Chris Wilson
2019-04-25  9:20 ` [PATCH 44/45] drm/i915/execlists: Preempt-to-busy Chris Wilson
2019-04-25  9:20 ` [PATCH 45/45] drm/i915/execlists: Minimalistic timeslicing Chris Wilson
2019-04-25 10:35 ` [PATCH 01/45] drm/i915: Seal races between async GPU cancellation, retirement and signaling Tvrtko Ursulin
2019-04-25 10:42   ` Chris Wilson
2019-04-26 10:40     ` Tvrtko Ursulin
2019-04-25 11:22 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/45] " Patchwork
2019-04-25 11:39 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-04-25 12:07 ` ✓ Fi.CI.BAT: success " Patchwork
2019-04-25 12:09 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/45] drm/i915: Seal races between async GPU cancellation, retirement and signaling (rev2) Patchwork
2019-04-25 12:25 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-04-25 12:56 ` ✓ Fi.CI.BAT: success " Patchwork
2019-04-25 21:52 ` ✗ Fi.CI.IGT: failure " 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=87r29prmm6.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).