From: Daniel Vetter <daniel@ffwll.ch>
To: Ben Widawsky <ben@bwidawsk.net>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Don't list gens one by bone in the VMA creation function
Date: Fri, 10 Jan 2014 18:33:46 +0100 [thread overview]
Message-ID: <20140110173346.GI4770@phenom.ffwll.local> (raw)
In-Reply-To: <20140110173249.GH4770@phenom.ffwll.local>
On Fri, Jan 10, 2014 at 06:32:49PM +0100, Daniel Vetter wrote:
> On Fri, Jan 10, 2014 at 09:16:39AM -0800, Ben Widawsky wrote:
> > On Fri, Jan 10, 2014 at 06:09:15PM +0100, Daniel Vetter wrote:
> > > On Fri, Jan 10, 2014 at 03:47:52PM +0000, Damien Lespiau wrote:
> > > > There are only two cases here, pre and post SNB (PPGTT).
> > > >
> > > > Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++------------
> > > > 1 file changed, 2 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > index 3192089..866ca90 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > > @@ -1795,10 +1795,7 @@ static struct i915_vma *__i915_gem_vma_create(struct drm_i915_gem_object *obj,
> > > > vma->vm = vm;
> > > > vma->obj = obj;
> > > >
> > > > - switch (INTEL_INFO(vm->dev)->gen) {
> > > > - case 8:
> > > > - case 7:
> > > > - case 6:
> > > > + if (INTEL_INFO(vm->dev)->gen >= 6) {
> > > > if (i915_is_ggtt(vm)) {
> > > > vma->unbind_vma = ggtt_unbind_vma;
> > > > vma->bind_vma = ggtt_bind_vma;
> > >
> > > Imo we should move the ->bind/unbind_vma functions into the global
> > > dev_prive->gt vtable - The personality we set here neither changes with
> > > the vma, the address space but the hw generation. So I'll reject this
> > > cleanup as not going far enough ;-)
> > > -Daniel
> >
> > Actually, it was wrong to begin with anyway. gen6 shouldn't have PPGTT
> > functions.
>
> If you want to go this far you can coalesce much more. _Everyone_ whether
> ppgtt or ggtt can use the same functions, which just call the insert/clear
> entries of the right vm. The exception is gen6 which needs to bind
> according to flags.
>
> All the few remaining checks for has_*_mapping we still have splattered
> over the code can be garbage-collected and converted to unconditional
> calls to ->vma_bind with the right flags set, since vma_bind will
> short-circuit correctly on gen6 (and not care anywhere else really).
s/gen6/aliasing_ppgtt/ in the above, i.e. it depends upon the runtime
option we're using in the driver ... Idea still holds.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
prev parent reply other threads:[~2014-01-10 17:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-10 15:47 [PATCH] drm/i915: Don't list gens one by bone in the VMA creation function Damien Lespiau
2014-01-10 17:09 ` Daniel Vetter
2014-01-10 17:16 ` Ben Widawsky
2014-01-10 17:32 ` Daniel Vetter
2014-01-10 17:33 ` Daniel Vetter [this message]
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=20140110173346.GI4770@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=ben@bwidawsk.net \
--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