From: Daniel Vetter <daniel@ffwll.ch>
To: Ben Widawsky <widawsky@gmail.com>
Cc: benjamin.widawsky@linux.intel.com, intel-gfx@lists.freedesktop.org
Subject: Re: [RFC] drm/i915: context support unit test
Date: Tue, 28 Dec 2010 23:36:17 +0100 [thread overview]
Message-ID: <20101228223616.GB5596@viiv.ffwll.ch> (raw)
In-Reply-To: <20101225225303.GA5311@snipes.kumite>
Hi Ben,
On Sat, Dec 25, 2010 at 02:53:04PM -0800, Ben Widawsky wrote:
> I am requesting comments on the unit test for the context support I will be
> adding. Attached is the unit test. I intend to create wrappers for the create
> and destroy Ioctls in libdrm, unless someone has a better solution to reuse the
> existing API. For the time being, I plan to use the rsvd1 field in the exec2
> structure to store the context.
>
> In summary, you'll see two new Ioctls in this test, and one new DRM API, but
> once it's cleaned up, it will probably be 3 new Ioctls, and 3 new DRM APIs.
> Also I realize this test doesn't cover a lot of the bad cases, but that will
> be included later.
Just a few questions on the api:
- How does this tie in with the multiple ringbuffer support? Is the kernel
supposed to lazily allocate contexts for each ring as soon as userspaces
uses it on a given ring for the first time? imho the simpler approach
than adding an explicit ring arg to the ctx_create ioctl.
- (Assuming that the context stores pointers to the indirect state
objects - public docs are unclear in that matter) How do you plan to
handle bo eviction? The simplest thing is probably to bail on execbuf
in the kernel and ask userspace to reissue a complete context. Also: How
does the kernel know that evicting/moving a given bo invalidates a
certain context? Do you intend to create that connection implicitly with
i915_gem_domain_instruction or with some new reloc flag?
> Thanks.
> Ben
Cheers, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2010-12-28 22:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-25 22:53 [RFC] drm/i915: context support unit test Ben Widawsky
2010-12-28 22:36 ` Daniel Vetter [this message]
2010-12-29 4:03 ` Ben Widawsky
2010-12-30 10:07 ` Daniel Vetter
2010-12-30 11:13 ` Chris Wilson
2010-12-30 12:48 ` Daniel Vetter
2010-12-30 20:21 ` Ben Widawsky
2010-12-31 0:48 ` Ben Widawsky
2010-12-31 9:31 ` Chris Wilson
2011-01-04 20:10 ` Daniel Vetter
2011-01-04 20:21 ` 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=20101228223616.GB5596@viiv.ffwll.ch \
--to=daniel@ffwll.ch \
--cc=benjamin.widawsky@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=widawsky@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