From: Daniel Vetter <daniel@ffwll.ch>
To: "Kristian Høgsberg" <krh@bitplanet.net>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] intel: Use I915_EXEC_NO_RELOC when available
Date: Wed, 21 Jan 2015 10:17:01 +0100 [thread overview]
Message-ID: <20150121091701.GF10113@phenom.ffwll.local> (raw)
In-Reply-To: <CAOeoa-cPBRp-L0PL1_yrSw0Fmywyq1HGc4uOSLuvoWvq+6cVRQ@mail.gmail.com>
On Tue, Jan 20, 2015 at 10:10:57PM -0800, Kristian Høgsberg wrote:
> However, drm_intel_bo_reference/unreference() is showing up on the
> profiles now that relocations are cheaper, but I think the better way
> to make those cheaper is to move the ref count to the public struct
> and make the ref/unref inline functions (calling out to a destructor
> for the refcount==0 case, of course). On that note, do you know why
> drm_intel_gem_bo_unreference() is so convoluted? What's the deal with
> the atomic_add_unless?
Smells like the last reference can only be dropped with the mutex held,
probably because someone is assuming that buffers don't go poof while
holding the mutex. You should be able to drop this after some refcounting
audit to make sure no one looks at a bo after the unref is done.
-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-01-21 9:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-17 1:45 [PATCH 1/2] intel: Use I915_EXEC_HANDLE_LUT when available Kristian Høgsberg
2015-01-17 1:46 ` [PATCH 2/2] intel: Use I915_EXEC_NO_RELOC " Kristian Høgsberg
2015-01-17 4:23 ` Daniel Vetter
2015-01-17 9:49 ` Chris Wilson
2015-01-20 5:58 ` Kristian Høgsberg
2015-01-20 8:34 ` Daniel Vetter
2015-01-20 5:45 ` Kristian Høgsberg
2015-01-20 8:42 ` Daniel Vetter
2015-01-20 20:53 ` Kristian Høgsberg
2015-01-20 21:46 ` Chris Wilson
2015-01-21 6:10 ` Kristian Høgsberg
2015-01-21 9:11 ` Daniel Vetter
2015-01-21 9:17 ` Daniel Vetter [this message]
2015-01-21 9:24 ` Daniel Vetter
2015-01-21 9:24 ` Chris Wilson
2015-01-17 9:46 ` [PATCH 1/2] intel: Use I915_EXEC_HANDLE_LUT " Chris Wilson
2015-05-01 14:53 ` RFC Fast batch and relocation handling for i965 Chris Wilson
2015-05-01 14:53 ` [PATCH 1/4] i965: Transplant PIPE_CONTROL routines to brw_pipe_control Chris Wilson
2015-05-01 17:58 ` Kenneth Graunke
2015-05-01 14:53 ` [PATCH 2/4] i915: Rename intel_emit* to reflect their new location in brw_pipe_control Chris Wilson
2015-05-01 14:53 ` [PATCH 3/4] i965: Move pipecontrol workaround bo to brw_pipe_control Chris Wilson
2015-05-01 14:53 ` [PATCH 4/4] i965: Introduce a context-local batch manager Chris Wilson
2015-05-05 16:16 ` [Mesa-dev] " Emil Velikov
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=20150121091701.GF10113@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=krh@bitplanet.net \
/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