[Intel-gfx] pin OABUFFER to GGTT

Wed Jul 2 12:31:45 CEST 2014

Ad>Tomasz: is the intention to only measure within a batch? My impression is
that you wanted to maintain the OABUFFER programmed and then collect
performance reports for a period of time (probably for several
batchbuffers). If that´s the case, the relocation approach is not possible.

I confirm that relocation approach is not possible.

OA buffer collect performance data for many hw contexts, and thus many batch
buffers, it is a hardware reporting mechanism not bound to any specific GPU
command send within a BB.

The report is triggered by hw when:
- hw context switches, that action can be caused by any level GPU
preemption, GUC direct context submission, and regular kernel exec list
submission
- GPU frequency change - that is trigger by power management
- RC6 transition
- time interval expiration (if programmed so for collect performance data at
regular time intervals)

Each instance of UMD maps then the OA buffer to examine it within the
Performance Query measurement window. Window is learned with Query::Begin
and Query::End timestamps and reported OABufferTail pointer on Query::End.
As OA buffer is large (up to 16MB), any KMD assist in conveying that data to
UMD on each Query::End is not applicable - queries might be done per each
Draw. There isn't any secret or privacy in that OA buffer data - just
results of performance counters, shown by tools such as GPA/ Vtune.

Thanks,
Tomasz

-----Original Message-----
From: Mateo Lozano, Oscar 
Sent: Wednesday, July 02, 2014 10:50 AM
To: Chris Wilson; Ben Widawsky
Cc: Intel-gfx at lists.freedesktop.org; Madajczak, Tomasz; Rutkowski, Adam J;
Jesse Barnes (jbarnes at virtuousgeek.org)
Subject: RE: [Intel-gfx] pin OABUFFER to GGTT

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47

> -----Original Message-----
> From: Chris Wilson [mailto:chris at chris-wilson.co.uk]
> Sent: Wednesday, July 02, 2014 7:56 AM
> To: Ben Widawsky
> Cc: Mateo Lozano, Oscar; Intel-gfx at lists.freedesktop.org; Madajczak, 
> Tomasz; Rutkowski, Adam J; Jesse Barnes (jbarnes at virtuousgeek.org)
> Subject: Re: [Intel-gfx] pin OABUFFER to GGTT
> 
> On Tue, Jul 01, 2014 at 11:40:52PM -0700, Ben Widawsky wrote:
> > 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.
> 
> If the intention was to only measure within a batch and the command 
> parser ensured that the register was cleared before the end of the batch,
fine.
> That's not an information leak nor do we keep the hardware pointing to 
> an unpinned buffer afterwards.
> Chris Wilson, Intel Open Source Technology Centre

Tomasz: is the intention to only measure within a batch? My impression is
that you wanted to maintain the OABUFFER programmed and then collect
performance reports for a period of time (probably for several
batchbuffers). If that´s the case, the relocation approach is not possible.

Chris: please notice that the bo_pin ioctl they were using until now
required root, so the information leak about other users was not that bad.
Still, I tend to agree that bo_pin for this is overkill and the programming
of OABUFFER should be carried out by the kernel (with some interface to
userspace so that they can retrieve the actual contents of the buffer...
root only of course). 

-- Oscar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7228 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140702/13ae4180/attachment.bin>
-------------- next part --------------
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140702/13ae4180/attachment.html>