From: Daniel Vetter <daniel@ffwll.ch>
To: John Harrison <John.C.Harrison@Intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/5] drm/i915: Trim the command parser allocations
Date: Mon, 23 Feb 2015 17:09:49 +0100 [thread overview]
Message-ID: <20150223160949.GD24485@phenom.ffwll.local> (raw)
In-Reply-To: <54DE29AA.9000604@Intel.com>
On Fri, Feb 13, 2015 at 04:43:22PM +0000, John Harrison wrote:
> On 13/02/2015 13:23, Chris Wilson wrote:
> >On Fri, Feb 13, 2015 at 01:08:59PM +0000, John Harrison wrote:
> >>>@@ -1155,40 +1154,30 @@ i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
> >>> batch_start_offset,
> >>> batch_len,
> >>> is_master);
> >>>- if (ret) {
> >>>- if (ret == -EACCES)
> >>>- return batch_obj;
> >>>- } else {
> >>>- struct i915_vma *vma;
> >>>+ if (ret)
> >>>+ goto err;
> >>>- memset(shadow_exec_entry, 0, sizeof(*shadow_exec_entry));
> >>>+ ret = i915_gem_obj_ggtt_pin(shadow_batch_obj, 0, 0);
> >>There is no explicit unpin for this. Does it happen automatically
> >>due to adding the vma to the eb->vmas list?
> >We set the exec_flag that tells us to unpin the obj when unwinding the
> >execbuf.
> >>Also, does it matter that it will be pinned again (and explicitly
> >>unpinned) if the SECURE flag is set?
> >No, pin/unpin is just a counter, it just needs to be balanced. (Long
> >answer, yes, the restrictions given to both pin requests much match or
> >else we will attempt to repin the buffer and fail miserably as the
> >object is already pinned.)
> >-Chris
> >
>
> Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-02-23 16:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-14 11:20 [PATCH 1/5] agp/intel: Serialise after GTT updates Chris Wilson
2015-01-14 11:20 ` [PATCH 2/5] drm/i915: Fallback to using CPU relocations for large batch buffers Chris Wilson
2015-01-15 9:45 ` Daniel, Thomas
2015-01-26 8:57 ` Jani Nikula
2015-01-27 15:09 ` Daniel Vetter
2015-01-27 21:43 ` Chris Wilson
2015-01-28 9:14 ` Daniel Vetter
2015-01-28 9:34 ` Chris Wilson
2015-01-14 11:20 ` [PATCH 3/5] drm/i915: Trim the command parser allocations Chris Wilson
2015-02-13 13:08 ` John Harrison
2015-02-13 13:23 ` Chris Wilson
2015-02-13 16:43 ` John Harrison
2015-02-23 16:09 ` Daniel Vetter [this message]
2015-01-14 11:20 ` [PATCH 4/5] drm/i915: Cache last obj->pages location for i915_gem_object_get_page() Chris Wilson
2015-02-13 13:33 ` John Harrison
2015-02-13 13:35 ` John Harrison
2015-02-13 14:28 ` Chris Wilson
2015-01-14 11:20 ` [PATCH 5/5] drm/i915: Tidy batch pool logic Chris Wilson
2015-01-14 20:54 ` shuang.he
2015-02-13 14:00 ` John Harrison
2015-02-13 14:57 ` Chris Wilson
2015-01-26 10:47 ` [PATCH v2] agp/intel: Serialise after GTT updates Chris Wilson
2015-01-27 14:58 ` Daniel Vetter
2015-01-27 21:44 ` Chris Wilson
2015-01-28 9:15 ` Daniel Vetter
2015-01-28 7:50 ` shuang.he
2015-02-06 0:11 ` [PATCH 1/5] " Jesse Barnes
2015-02-06 8:31 ` Chris Wilson
2015-02-06 8:32 ` Daniel Vetter
2015-02-13 8:59 ` Ville Syrjälä
2015-02-13 9:25 ` Chris Wilson
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=20150223160949.GD24485@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=John.C.Harrison@Intel.com \
--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.