From: Daniel Vetter <daniel@ffwll.ch>
To: Eric Anholt <eric@anholt.net>
Cc: intel-gfx@lists.freedesktop.org,
Eugeni Dodonov <eugeni.dodonov@intel.com>
Subject: Re: [PATCH] drm/i915: add a LLC feature flag in device description
Date: Tue, 13 Dec 2011 18:57:51 +0100 [thread overview]
Message-ID: <20111213175751.GC4125@phenom.ffwll.local> (raw)
In-Reply-To: <87iplkie1j.fsf@eliezer.anholt.net>
On Tue, Dec 13, 2011 at 09:20:40AM -0800, Eric Anholt wrote:
> On Tue, 13 Dec 2011 17:09:37 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Tue, Dec 13, 2011 at 11:05:15AM -0200, Eugeni Dodonov wrote:
> > > From: Eugeni Dodonov <eugeni.dodonov@intel.com>
> > >
> > > LLC is not SNB-specific, so we should check for it in a more generic way.
> > >
> > > v2: export LLC support status via debugfs and DRM GETPARAM.
> > >
> > > Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> >
> > Nice patch and would get an r-b from me safe for the new GETPARAM. I
> > really think we need to export this on a per-bo basis (and with the caveat
> > that the kernel is free to change the caching on every ioctl that uses
> > it). I.e. without forcing userspace to check the caching bits before any
> > bo access I fear that we won't be able to change the kernel's behaviour in
> > this area, which surely results in backwards-compat hell when the first
> > w/a that needs such changes comes around. Hence in its current from
> >
> > Nacked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> >
> > So please drop the GETPARAM. For the per-bo get_cache_flags ioctl there's
> > already a patch by Ben floating around.
>
> The way the getparam would be useful is that right now we're taking some
> different paths for performance reasons in Mesa on gen6, assuming that
> LLC is present. Knowing whether or not we expect BOs in general to be
> LLC for performance would be nice for that -- without that, I'll just
> make assumptions based on chipset generation.
Ok, I'll reconsider: In the mesa example (and any other use-case for llc
accelarated up/download) we don't depend upon llc for correctness and
we're using the caching on a newly created buffer, so the per-bo ioctls
aren't much use. So I think the backwards-compat mess is manageable if
people promise to use the HAS_LLC getparam only for such optimizations ...
I still think we want to full get/set_cache_level in additions to this.
But for this patch:
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2011-12-13 17:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-13 0:05 [PATCH] drm/i915: add a LLC feature flag in device description Eugeni Dodonov
2011-12-13 0:19 ` Chris Wilson
2011-12-13 13:05 ` Eugeni Dodonov
2011-12-13 13:24 ` Chris Wilson
2011-12-13 16:09 ` Daniel Vetter
2011-12-13 17:20 ` Eric Anholt
2011-12-13 17:57 ` Daniel Vetter [this message]
2011-12-13 21:05 ` Eugeni Dodonov
2012-01-16 21:55 ` Daniel Vetter
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=20111213175751.GC4125@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=eric@anholt.net \
--cc=eugeni.dodonov@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox