Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 5d82e3e6 authored by Chris Wilson's avatar Chris Wilson Committed by Daniel Vetter
Browse files

drm/i915: Clarify the semantics of tiling_changed



Rename obj->tiling_changed to obj->fence_dirty so that it is clear that
it flags when the parameters for an active fence (including the
no-fence) register are changed.

Also, do not set this flag when the object does not have a fence
register allocated currently and the gpu does not depend upon the
unfence. This case works exactly like when a tiled object lost its
fence and hence does not need additional handling for the tiling
change in the code.

v2: Use fence_dirty to better express what the flag tracks and add a few
more details to the comments to serve as a reminder of how the GPU also
uses the unfenced register slot.

Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
[danvet: Add some bikeshed to the commit message about the stricter
use of fence_dirty.]
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
parent 38de45c5
Loading
Loading
Loading
Loading
+8 −1
Original line number Diff line number Diff line
@@ -869,7 +869,14 @@ struct drm_i915_gem_object {
	 * Current tiling mode for the object.
	 */
	unsigned int tiling_mode:2;
	unsigned int tiling_changed:1;
	/**
	 * Whether the tiling parameters for the currently associated fence
	 * register have changed. Note that for the purposes of tracking
	 * tiling changes we also treat the unfenced register, the register
	 * slot that the object occupies whilst it executes a fenced
	 * command (such as BLT on gen2/3), as a "fence".
	 */
	unsigned int fence_dirty:1;

	/** How many users have pinned this object in GTT space. The following
	 * users can each hold at most one reference: pwrite/pread, pin_ioctl
+4 −4
Original line number Diff line number Diff line
@@ -66,7 +66,7 @@ static inline void i915_gem_object_fence_lost(struct drm_i915_gem_object *obj)
	/* As we do not have an associated fence register, we will force
	 * a tiling change if we ever need to acquire one.
	 */
	obj->tiling_changed = false;
	obj->fence_dirty = false;
	obj->fence_reg = I915_FENCE_REG_NONE;
}

@@ -2459,7 +2459,7 @@ i915_gem_object_get_fence(struct drm_i915_gem_object *obj)
	/* Have we updated the tiling parameters upon the object and so
	 * will need to serialise the write to the associated fence register?
	 */
	if (obj->tiling_changed) {
	if (obj->fence_dirty) {
		ret = i915_gem_object_flush_fence(obj);
		if (ret)
			return ret;
@@ -2468,7 +2468,7 @@ i915_gem_object_get_fence(struct drm_i915_gem_object *obj)
	/* Just update our place in the LRU if our fence is getting reused. */
	if (obj->fence_reg != I915_FENCE_REG_NONE) {
		reg = &dev_priv->fence_regs[obj->fence_reg];
		if (!obj->tiling_changed) {
		if (!obj->fence_dirty) {
			list_move_tail(&reg->lru_list,
				       &dev_priv->mm.fence_list);
			return 0;
@@ -2491,7 +2491,7 @@ i915_gem_object_get_fence(struct drm_i915_gem_object *obj)
		return 0;

	i915_gem_object_update_fence(obj, reg, enable);
	obj->tiling_changed = false;
	obj->fence_dirty = false;

	return 0;
}
+9 −1
Original line number Diff line number Diff line
@@ -355,6 +355,11 @@ i915_gem_set_tiling(struct drm_device *dev, void *data,
		 * no longer meets the alignment restrictions for its new
		 * tiling mode. Otherwise we can just leave it alone, but
		 * need to ensure that any fence register is cleared.
		 *
		 * After updating the tiling parameters, we then flag whether
		 * we need to update an associated fence register. Note this
		 * has to also include the unfenced register the GPU uses
		 * whilst executing a fenced command for an untiled object.
		 */
		i915_gem_release_mmap(obj);

@@ -374,7 +379,10 @@ i915_gem_set_tiling(struct drm_device *dev, void *data,
		}

		if (ret == 0) {
			obj->tiling_changed = true;
			obj->fence_dirty =
				obj->fenced_gpu_access ||
				obj->fence_reg != I915_FENCE_REG_NONE;

			obj->tiling_mode = args->tiling_mode;
			obj->stride = args->stride;
		}