From: Ben Widawsky <ben@bwidawsk.net>
To: Chris Wilson <chris@chris-wilson.co.uk>,
"Mateo Lozano, Oscar" <oscar.mateo@intel.com>,
"Intel-gfx@lists.freedesktop.org"
<Intel-gfx@lists.freedesktop.org>,
"Madajczak, Tomasz" <Tomasz.Madajczak@intel.com>,
"Rutkowski, Adam J" <adam.j.rutkowski@intel.com>,
"Jesse Barnes (jbarnes@virtuousgeek.org)"
<jbarnes@virtuousgeek.org>
Subject: Re: pin OABUFFER to GGTT
Date: Tue, 1 Jul 2014 23:40:52 -0700 [thread overview]
Message-ID: <20140702064052.GA2723@bwidawsk.net> (raw)
In-Reply-To: <20140701195427.GA11155@nuc-i3427.alporthouse.com>
On Tue, Jul 01, 2014 at 08:54:27PM +0100, Chris Wilson wrote:
> On Tue, Jul 01, 2014 at 05:16:30PM +0000, Mateo Lozano, Oscar wrote:
> > > The issue is they need:
> > >
> > > A) A buffer object.
> > > B) Bound to GGTT.
> > > C) That userspace knows the GGTT offset of, so that they can program
> > > OABUFFER with it.
> > > D) That userspace can map so that they can read the reported counters.
> > >
> > > They used to create a bo, call bo_pin on it, use args->offset to program
> > > OABUFFER (via MI_LOAD_REGISTER_IMM, I imagine), map it and read the
> > > counter values. They cannot do this anymore.
> >
> > The answer might be that all of this needs to be done by the kernel itself, but then we need to provide an interface to userspace...
>
> Yes. If you need to pin a buffer for a register, then it needs to be
> handled by the kernel. Especially one that provides information about
> other users.
> -Chris
>
I'm unclear why they need the offset. Can it not work like any other
relocation, except with the requirement that it's in the GGTT?
I'd also argue that they need to be able to map it (they need the
contents, which may or may not be mapped). However, I think this is a
very minor point.
With the command validator this should be a pretty reasonable thing to
accomplish. I think we can just give a flag for the reloc that it needs
to be in the GGTT, and then pass a check to the command scanner that
only that one offset is allowed, and only for OA.
--
Ben Widawsky, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-07-02 6:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-01 16:24 pin OABUFFER to GGTT Mateo Lozano, Oscar
2014-07-01 16:30 ` Chris Wilson
2014-07-01 16:34 ` Mateo Lozano, Oscar
2014-07-01 16:51 ` Chris Wilson
2014-07-01 17:13 ` Mateo Lozano, Oscar
2014-07-01 17:16 ` Mateo Lozano, Oscar
2014-07-01 19:54 ` Chris Wilson
2014-07-02 6:40 ` Ben Widawsky [this message]
2014-07-02 6:55 ` Chris Wilson
2014-07-02 8:49 ` Mateo Lozano, Oscar
2014-07-02 10:31 ` Madajczak, Tomasz
2014-07-02 10:49 ` Damien Lespiau
2014-07-02 11:11 ` Madajczak, Tomasz
2014-07-02 13:19 ` Rutkowski, Adam J
2014-07-03 7:17 ` Damien Lespiau
2014-07-03 17:10 ` Ben Widawsky
2014-07-03 20:45 ` Ben Widawsky
2014-07-02 17:36 ` Ben Widawsky
2014-07-07 20:43 ` Daniel Vetter
2014-07-07 23:59 ` Bragg, Robert
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=20140702064052.GA2723@bwidawsk.net \
--to=ben@bwidawsk.net \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=Tomasz.Madajczak@intel.com \
--cc=adam.j.rutkowski@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=jbarnes@virtuousgeek.org \
--cc=oscar.mateo@intel.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