From: Chris Wilson <chris@chris-wilson.co.uk>
To: Damien Lespiau <damien.lespiau@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: Re-order some checks to do the unlikely one first
Date: Tue, 17 Feb 2015 21:10:46 +0000 [thread overview]
Message-ID: <20150217211046.GD24636@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <20150217114825.GB27908@strange.ger.corp.intel.com>
On Tue, Feb 17, 2015 at 11:48:25AM +0000, Damien Lespiau wrote:
> On Mon, Feb 16, 2015 at 09:03:51PM +0000, Chris Wilson wrote:
> > On Mon, Feb 16, 2015 at 06:25:10PM +0000, Damien Lespiau wrote:
> > > instpm_mode != relative_constants_mode is quite unlikely to happen, so
> > > we can test it first to use C's && short-circuiting and not test on
> > > 'ring'.
> > >
> > > I know, probably a useless micro-optimisation in the big scheme of
> > > things, but I'm going to add another test here, so might as well do it.
> >
> > If you want to get pedantic, we want to move this to per-context :)
>
> Do we? the API is per execbuf call, so theoretically application can
> change that during the context life time (it'd be silly, but they can).
> Or am I missing the point?
It was that this is a context specific register and more about handling
the transaction unwind if the execbuffer were to fail later i.e. an
issue about to arise with new features modifying the code. But in theory
we could do fewer LRI for that one application that used it...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
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-17 21:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-16 18:25 [PATCH 1/2] drm/i915: Re-order some checks to do the unlikely one first Damien Lespiau
2015-02-16 18:25 ` [PATCH 2/2] drm/i915: Don't try to set INSTPM for the _ABSOLUTE constant buffer address Damien Lespiau
2015-02-17 5:45 ` shuang.he
2015-02-23 23:24 ` Daniel Vetter
2015-02-16 21:03 ` [PATCH 1/2] drm/i915: Re-order some checks to do the unlikely one first Chris Wilson
2015-02-17 11:48 ` Damien Lespiau
2015-02-17 21:10 ` Chris Wilson [this message]
2015-02-19 10:26 ` Dave Gordon
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=20150217211046.GD24636@nuc-i3427.alporthouse.com \
--to=chris@chris-wilson.co.uk \
--cc=damien.lespiau@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.