All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Subject: Re: [PATCH 2/2] drm/i915: Mark obj->mapping as dirtying the backing storage
Date: Thu, 21 Apr 2016 11:02:25 +0100	[thread overview]
Message-ID: <5718A531.1010902@intel.com> (raw)
In-Reply-To: <20160412151840.GC21985@nuc-i3427.alporthouse.com>

On 12/04/16 16:18, Chris Wilson wrote:
> On Tue, Apr 12, 2016 at 02:32:31PM +0100, Chris Wilson wrote:
>> When reviewing some of Tvrtko's usage for i915_gem_object_pin_map(), he
>> suggested replacing some use of kmap(i915_gem_object_get_dirty_page())
>> with a plain i915_gem_object_pin_map(). This raised the question of who
>> should mark the page as dirty (or the mapping case, the object).
>> We can write simpler, safer code if we mark the entire object as dirty
>> upon obtaining the obj->mapping. (The counter-argument is that the
>> caller should be marking the object as dirty itself, or we should be
>> passing in a direction parameter.)
>
> What I particularly dislike about the current obj->dirty is that it is
> strictly only valid inside a pin_pages/unpin_pages section. That isn't
> clear from the API atm.
> -Chris

So, I tried replacing all instances of "obj->dirty = true" with my new 
function i915_gem_object_mark_dirty(), and added an assertion that it's 
called only when (pages_pin_count > 0) - and found a failure.

Stack is:
	i915_gem_object_mark_dirty
	i915_gem_object_set_to_gtt_domain
	i915_gem_set_domain_ioctl

So is i915_gem_object_set_to_gtt_domain() wrong? It's done a get_pages 
but no pin_pages. Also, i915_gem_object_set_to_cpu_domain() doesn't mark 
the object dirty in the corresponding if(write) clause - is that also wrong?

.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2016-04-21 10:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-12 13:32 [PATCH 1/2] drm/i915: Fix up ERR_PTR handling for pinning the ringbuffer Chris Wilson
2016-04-12 13:32 ` [PATCH 2/2] drm/i915: Mark obj->mapping as dirtying the backing storage Chris Wilson
2016-04-12 15:18   ` Chris Wilson
2016-04-20 19:38     ` Dave Gordon
2016-04-21 10:02     ` Dave Gordon [this message]
2016-04-12 13:46 ` [PATCH] drm/i915: check for ERR_PTR from i915_gem_object_pin_map() Dave Gordon
2016-04-12 13:53   ` Chris Wilson
2016-04-12 16:03 ` ✗ Fi.CI.BAT: failure for series starting with drm/i915: check for ERR_PTR from i915_gem_object_pin_map() (rev2) Patchwork
2016-04-12 16:29   ` Dave Gordon
2016-04-20 16:01     ` Tvrtko Ursulin

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=5718A531.1010902@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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 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.