public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: Paul Berry <stereotype441@gmail.com>
Cc: Mesa Dev <mesa-dev@lists.freedesktop.org>,
	intel-gfx@lists.freedesktop.org,
	DRI Devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 25/25] i965: hw context support
Date: Mon, 4 Jun 2012 16:10:56 -0700	[thread overview]
Message-ID: <20120604161056.3a3a084d@bwidawsk.net> (raw)
In-Reply-To: <CA+yLL64CoJJRpkJYFAWY_Cq9+pKNowXBaKJdt6AJ8CMW3kJa8w@mail.gmail.com>

On Mon, 4 Jun 2012 16:01:54 -0700
Paul Berry <stereotype441@gmail.com> wrote:

> On 4 June 2012 14:43, Ben Widawsky <ben@bwidawsk.net> wrote:
> 
> > Based off of a patch from Ken Graunke. I just modified it for a more
> > modern mesa (also don't allow contexts on blit ring).
> >
> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> > ---
> >  src/mesa/drivers/dri/i965/brw_context.c        |    1 +
> >  src/mesa/drivers/dri/i965/brw_vtbl.c           |    5 ++++-
> >  src/mesa/drivers/dri/intel/intel_batchbuffer.c |    9 +++++++--
> >  src/mesa/drivers/dri/intel/intel_context.c     |    2 ++
> >  src/mesa/drivers/dri/intel/intel_context.h     |    2 +-
> >  5 files changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> > b/src/mesa/drivers/dri/i965/brw_context.c
> > index f7073cd..d4159c7 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> > @@ -298,6 +298,7 @@ brwCreateContext(int api,
> >
> >    brw->prim_restart.in_progress = false;
> >    brw->prim_restart.enable_cut_index = false;
> > +   intel->hw_ctx = drm_intel_gem_context_create(intel->bufmgr);
> >
> >    brw_init_state( brw );
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_vtbl.c
> > b/src/mesa/drivers/dri/i965/brw_vtbl.c
> > index 5699749..d9fd2cb 100644
> > --- a/src/mesa/drivers/dri/i965/brw_vtbl.c
> > +++ b/src/mesa/drivers/dri/i965/brw_vtbl.c
> > @@ -170,7 +170,10 @@ static void brw_new_batch( struct intel_context
> > *intel )
> >     * This is probably not as severe as on 915, since almost all of our
> > state
> >     * is just in referenced buffers.
> >     */
> > -   brw->state.dirty.brw |= BRW_NEW_CONTEXT | BRW_NEW_BATCH;
> > +   if (intel->hw_ctx == NULL)
> > +      brw->state.dirty.brw |= BRW_NEW_CONTEXT;
> > +
> > +   brw->state.dirty.brw |= BRW_NEW_BATCH;
> >
> 
> The comment above this change ("Mark all context state as needing to be
> re-emitted.") is no longer accurate.  Perhaps change it to something like
> this?
> 
> "If the kernel supports hardware contexts, then most hardware state is
> preserved between batches; we only need to re-emit state that is required
> to be in every batch.  Otherwise we need to re-emit all the state that
> would otherwise be stored in the context (which for all intents and
> purposes means everything)."
> 
> Also, I think it would be ok to delete the comment "This is probably not as
> severe as on 915 ... referenced buffers"--that comment is mostly just a
> rationalization for not having implemented hardware context support
> earlier, and not a very convincing one at that :)
> 
> 
> >
> >    /* Assume that the last command before the start of our batch was a
> >     * primitive, for safety.
> > diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> > b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> > index 76a69f7..7ba141d 100644
> > --- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> > +++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
> > @@ -188,8 +188,13 @@ do_flush_locked(struct intel_context *intel)
> >       if (ret == 0) {
> >          if (unlikely(INTEL_DEBUG & DEBUG_AUB) && intel->vtbl.annotate_aub)
> >             intel->vtbl.annotate_aub(intel);
> > -        ret = drm_intel_bo_mrb_exec(batch->bo, 4*batch->used, NULL, 0, 0,
> > -                                    flags);
> > +        if (intel->hw_ctx == NULL || batch->is_blit) {
> > +           ret = drm_intel_bo_mrb_exec(batch->bo, 4*batch->used, NULL, 0,
> > 0,
> > +                                       flags);
> > +        } else {
> > +           ret = drm_intel_gem_bo_context_exec(batch->bo, intel->hw_ctx,
> > +                                           4 * batch->used, flags);
> > +        }
> >       }
> >    }
> >
> > diff --git a/src/mesa/drivers/dri/intel/intel_context.c
> > b/src/mesa/drivers/dri/intel/intel_context.c
> > index 9deb4ca..46c2492 100644
> > --- a/src/mesa/drivers/dri/intel/intel_context.c
> > +++ b/src/mesa/drivers/dri/intel/intel_context.c
> > @@ -593,6 +593,8 @@ intelInitContext(struct intel_context *intel,
> >    if (intelScreen->bufmgr == NULL)
> >       return false;
> >
> > +   intel->hw_ctx = NULL;
> > +
> >    /* Can't rely on invalidate events, fall back to glViewport hack */
> >    if (!driContextPriv->driScreenPriv->dri2.useInvalidate) {
> >       intel->saved_viewport = functions->Viewport;
> > diff --git a/src/mesa/drivers/dri/intel/intel_context.h
> > b/src/mesa/drivers/dri/intel/intel_context.h
> > index cc3ee0d..c026fea 100644
> > --- a/src/mesa/drivers/dri/intel/intel_context.h
> > +++ b/src/mesa/drivers/dri/intel/intel_context.h
> > @@ -226,7 +226,7 @@ struct intel_context
> >    int urb_size;
> >
> >    struct intel_batchbuffer batch;
> > -
> > +   drm_intel_context *hw_ctx;
> >    drm_intel_bo *first_post_swapbuffers_batch;
> >    bool need_throttle;
> >    bool no_batch_wrap;
> > --
> > 1.7.10.2
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> 
> I'm kind of surprised to see a call to drm_intel_gem_context_create(), but
> no call anywhere to a clean-up function that destroys the context.  Was
> that an oversight, or is there a reason why it's unnecessary?  If it's the
> latter, a comment in brw_destroy_context() would be helpful.

Destroying a context is not required, though it is desirable. The
context will be destroyed when the DRM file handle is closed. I think I
had that info in a comment somewhere, but I forget exactly where it is.
I'd propose mesa people find a good place for destroy as the best
solution :-)


-- 
Ben Widawsky, Intel Open Source Technology Center

  reply	other threads:[~2012-06-04 23:10 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-04 21:42 [PATCH 00/25] i915 HW context support Ben Widawsky
2012-06-04 21:42 ` [PATCH 01/25] drm/i915: CXT_SIZE register offsets added Ben Widawsky
2012-06-04 21:42 ` [PATCH 02/25 v2] drm/i915: preliminary context support Ben Widawsky
2012-06-05 12:23   ` Ville Syrjälä
2012-06-05 16:30     ` Ben Widawsky
2012-06-04 21:42 ` [PATCH 03/25 v2] drm/i915: context basic create & destroy Ben Widawsky
2012-06-13 23:27   ` Ben Widawsky
2012-06-04 21:42 ` [PATCH 04/25] drm/i915: add context information to objects Ben Widawsky
2012-06-13 22:01   ` Daniel Vetter
2012-06-13 23:26     ` Ben Widawsky
2012-06-04 21:42 ` [PATCH 05/25] drm/i915: always bind context objects immediately Ben Widawsky
2012-06-04 21:42 ` [PATCH 06/25 v3] drm/i915: context switch implementation Ben Widawsky
2012-06-04 21:42 ` [PATCH 07/25] drm/i915: context trace events Ben Widawsky
2012-06-13 22:23   ` Daniel Vetter
2012-06-13 23:27     ` Ben Widawsky
2012-06-04 21:42 ` [PATCH 08/25] drm/i915: Ivybridge MI_ARB_ON_OFF context w/a Ben Widawsky
2012-06-04 21:42 ` [PATCH 09/25] drm/i915: PIPE_CONTROL_TLB_INVALIDATE Ben Widawsky
2012-06-04 21:42 ` [PATCH 10/25 v2] drm/i915: possibly invalidate TLB before context switch Ben Widawsky
2012-06-04 21:42 ` [PATCH 11/25] drm/i915: use the default context Ben Widawsky
2012-06-04 21:42 ` [PATCH 12/25] drm/i915: add ccid to error state Ben Widawsky
2012-06-04 21:42 ` [PATCH 13/25 v3] drm/i915: switch to default context on idle Ben Widawsky
2012-06-04 21:42 ` [PATCH 14/25 v3] drm/i915/context: create & destroy ioctls Ben Widawsky
2012-06-04 21:42 ` [PATCH 15/25 v2] drm/i915/context: switch contexts with execbuf2 Ben Widawsky
2012-06-04 21:42 ` [PATCH 16/25] drm/i915: reset the GPU on context fini Ben Widawsky
2012-06-04 21:42 ` [PATCH 17/25] intel: wait render placeholder Ben Widawsky
2012-06-04 21:42 ` [PATCH 18/25] intel: Merge updated kernel header Ben Widawsky
2012-06-04 21:42 ` [PATCH 19/25] intel/context: Add drm_intel_context type Ben Widawsky
2012-06-04 21:43 ` [PATCH 20/25] intel/context: new execbuf interface for contexts Ben Widawsky
2012-06-04 21:43 ` [PATCH 21/25] intel: add decoding of MI_SET_CONTEXT Ben Widawsky
2012-06-04 21:43 ` [PATCH 22/25] context: libdrm wrappers Ben Widawsky
2012-06-04 21:43 ` [PATCH 23/25] context: update for new execbuf2 element Ben Widawsky
2012-06-04 21:43 ` [PATCH 24/25] contexts: basic test coverage Ben Widawsky
2012-06-13 23:30   ` Daniel Vetter
2012-06-14  3:13   ` [PATCH] " Ben Widawsky
2012-06-04 21:43 ` [PATCH 25/25] i965: hw context support Ben Widawsky
2012-06-04 23:01   ` Paul Berry
2012-06-04 23:10     ` Ben Widawsky [this message]
2012-06-05  5:53 ` [PATCH 00/25] i915 HW " Dave Airlie
2012-06-05  7:08   ` [Mesa-dev] " Kenneth Graunke
2012-06-05 16:32     ` Ben Widawsky
2012-06-05 23:37 ` Kenneth Graunke
2012-06-07 16:17   ` Ben Widawsky
2012-06-14 16:04 ` 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=20120604161056.3a3a084d@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mesa-dev@lists.freedesktop.org \
    --cc=stereotype441@gmail.com \
    /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