All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Ben Widawsky <bwidawsk@gmail.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/8] drm/i915/context: context validation for execbuffer2
Date: Mon, 14 Feb 2011 21:21:22 +0100	[thread overview]
Message-ID: <20110214202122.GA3569@viiv.ffwll.ch> (raw)
In-Reply-To: <1296687620-27019-6-git-send-email-bwidawsk@gmail.com>

On Wed, Feb 02, 2011 at 03:00:17PM -0800, Ben Widawsky wrote:
> Adds the support for actually doing something with buffer validation for
> the context when submitted via execbuffer2. When a set of context flags
> are submitted in the execbuffer call, the code is able to handle the
> commands. It will also go through the existing buffers associated with
> the context and make sure they are still present. The big thing missing
> is if the client wants to change the domains of buffers which have
> already been associated. In this case, the client must disassociate and
> then re-associate with the proper domains.

Hm, this remark got me thinking (because currently with read/write domains
per reloc domain changes on the fly are super-simple): Why not drop the
whole associate/disassociate idea and require userspace to always submit a
full list of bos still used by this context (and their required
offsets)?

Upsides:
- No fiddling when reused bos change domains.
- No need to track stuff in the kernel, we only check the offsets.
- Userspace implementation sounds rather straightforward, too: If the
  aperture check fails, submit the batchbuffer and then store all bos
  bound to the current gl context (assuming a one-on-one hw context <-> gl
  context mapping) and their desired domains (also easy because the usage
  is known). Then on the next execbuffer use that stored array for the
  additionally required bos (your flag array).
- Improvements like ppgtt or (re-)pinning bos at the right place can still
  be added incrementally. After all, you already require userspace to be
  able to do a full context restore as part of your abi ...
Downsides:
- Might no be optimal. But given our constant fiddling with the
  batchbuffer submission, expecting to get this right on the first try is
  probably wishful thinking.

Just my 2 (constantly changing) cents on this. Anyway, you've thought much
more about this than me, so I expect you to shoot this down in a
half-sentence ... ;)

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2011-02-14 20:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-02 23:00 [PATCH 0/8] drm/i915/context Ben Widawsky
2011-02-02 23:00 ` [PATCH 1/8] drm/i915/context: basic implementation context ioctls Ben Widawsky
2011-02-02 23:00 ` [PATCH 2/8] drm/i915/context: context initialization/destruction Ben Widawsky
2011-02-02 23:00 ` [PATCH 3/8] drm/i915/context: whitespace cleanup, and warning cleanup Ben Widawsky
2011-02-02 23:00 ` [PATCH 4/8] drm/i915/context: minimal support for contexts in execbuffer2 Ben Widawsky
2011-02-02 23:00 ` [PATCH 5/8] drm/i915/context: context validation for execbuffer2 Ben Widawsky
2011-02-14 20:21   ` Daniel Vetter [this message]
2011-02-14 23:10     ` Ben Widawsky
2011-02-02 23:00 ` [PATCH 6/8] drm/i915/context: enable calling context_switch Ben Widawsky
2011-02-02 23:00 ` [PATCH 7/8] drm/i915/context: Insert MI_SET_CONTEXT in ringbuffer context switch Ben Widawsky
2011-02-02 23:00 ` [PATCH 8/8] drm/i915/context: context switch, and PPGTT params Ben Widawsky
2011-02-02 23:29 ` [PATCH 0/8] drm/i915/context Chris Wilson
2011-02-02 23:55   ` Ben Widawsky

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=20110214202122.GA3569@viiv.ffwll.ch \
    --to=daniel@ffwll.ch \
    --cc=bwidawsk@gmail.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.