On Wed, Aug 2, 2017 at 2:28 AM, Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> On 01/08/17 19:05, sourab gupta wrote:
>
>
>
> On Tue, Aug 1, 2017 at 2:59 PM, Kamble, Sagar A
> wrote:
>
>>
>>
>> -Original Message-
>> From: La
On Thu, 2017-03-16 at 05:59 -0700, Robert Bragg wrote:
> On Thu, Mar 16, 2017 at 6:14 AM, wrote:
> > From: Sourab Gupta
> >
> > This series adds framework for collection of OA reports associated with the
> > render command stream, which are collected ar
On Thu, 2017-03-16 at 03:09 -0700, Chris Wilson wrote:
> On Thu, Mar 16, 2017 at 03:22:03PM +0530, sourab gupta wrote:
> > On Thu, 2017-03-16 at 02:03 -0700, Chris Wilson wrote:
> > > On Thu, Mar 16, 2017 at 02:24:55PM +0530, sourab gupta wrote:
> > > > On Thu, 20
On Thu, 2017-03-16 at 02:03 -0700, Chris Wilson wrote:
> On Thu, Mar 16, 2017 at 02:24:55PM +0530, sourab gupta wrote:
> > On Thu, 2017-03-16 at 01:10 -0700, Chris Wilson wrote:
> > > On Thu, Mar 16, 2017 at 11:44:10AM +0530, sourab.gu...@intel.com wrote:
> > > &
On Thu, 2017-03-16 at 01:31 -0700, Chris Wilson wrote:
> On Thu, Mar 16, 2017 at 11:44:10AM +0530, sourab.gu...@intel.com wrote:
> > +static void i915_perf_command_stream_hook_oa(struct i915_perf_stream
> > *stream,
> > + struct drm_i915_gem_request *request)
> >
On Thu, 2017-03-16 at 01:10 -0700, Chris Wilson wrote:
> On Thu, Mar 16, 2017 at 11:44:10AM +0530, sourab.gu...@intel.com wrote:
> > @@ -3593,6 +3670,7 @@ void i915_oa_init_reg_state(struct intel_engine_cs
> > *engine,
> > void i915_oa_update_reg_state(struct intel_engine_cs *engine,
> >
On Thu, 2017-03-16 at 00:49 -0700, Chris Wilson wrote:
> On Thu, Mar 16, 2017 at 11:50:06AM +0530, sourab.gu...@intel.com wrote:
> > From: Sourab Gupta
> >
> > This patch extends the i915 perf framework to handle the perf sample
> > collection for any given gpu engine
From: Sourab Gupta
Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports or PIPE_CONTROL commands
inserted in the ring). This limits the ability to correlate these samples
with the system events. If we scale the GPU timestamps
From: Sourab Gupta
This patch adds support for capturing MMIO register values through
i915 perf interface.
The userspace can request upto 8 MMIO register values to be dumped.
The addresses of these registers can be passed through the corresponding
property 'value' field while opening
From: Sourab Gupta
For the drivers to be able to use the cross timestamp framework,
they need the information of current clocksource being used by the
kernel timekeeping. This is needed since the callback given by driver
into the get_device_system_crosststamp(), in order to synchronously read
From: Sourab Gupta
This patch adds support for opening multiple concurrent perf streams for
different gpu engines, while having the restriction to open only a single
stream open for a particular gpu engine.
This enables userspace client to open multiple streams, one per engine,
at any time to
From: Sourab Gupta
The OA reports contain the least significant 32 bits of the gpu timestamp.
This patch enables retrieval of the timestamp field from OA reports, to
forward as 64 bit raw gpu timestamps in the perf samples.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_drv.h | 1
From: Sourab Gupta
This patch extends the i915 perf framework to handle the perf sample
collection for any given gpu engine. Particularly, the support
for collecting timestamp sample type is added, which can be requested for
any engine.
With this, for RCS, timestamps and OA reports can be
From: Sourab Gupta
This series adds framework for collection of gpu performance metrics
associated with the command stream of a particular engine. These metrics
include OA reports for render stream and timestamps, mmio metrics, etc. for
other gpu engine streams. These metrics are are collected
From: Sourab Gupta
This adds support for populating the ctx id for the periodic OA reports
when requested through the corresponding property.
For Gen8, the OA reports itself have the ctx ID and it is the one programmed
into HW while submitting workloads. Thus it's retrieved from reports i
From: Sourab Gupta
This patch introduces a framework to capture OA counter reports associated
with Render command stream. We can then associate the reports captured
through this mechanism with their corresponding context id's. This can be
further extended to associate any other met
From: Sourab Gupta
Considering how we don't currently give userspace control over the
OA buffer size and always configure a large 16MB buffer,
then a buffer overflow does anyway likely indicate that something
has gone quite badly wrong.
Here we set a status flag to detect overflow and i
From: Sourab Gupta
This patch exposes a new sample source field to userspace. This field can
be populated to specify the origin of the OA report.
Currently, the OA samples are being generated only periodically, and hence
there's only source flag enum definition right now, but there are
From: Sourab Gupta
When there are no pending CS OA samples, flush the periodic OA samples
collected so far.
We can safely forward the periodic OA samples in the case we
have no pending CS samples, but we can't do so in the case we have
pending CS samples, since we don't know what th
From: Sourab Gupta
This patch introduces flags and adds support for having pid output with
the OA reports generated through the RCS commands.
When the stream is opened with pid sample type, the pid information is also
captured through the command stream samples and forwarded along with the
OA
From: Sourab Gupta
This patch enables userspace to specify tags (per workload), provided via
execbuffer ioctl, which could be added to OA reports, to help associate
reports with the corresponding workloads.
There may be multiple stages within a single context, from a userspace
perspective. An
From: Sourab Gupta
This patch adds a new ctx getparam ioctl parameter, which can be used to
retrieve ctx unique id by userspace.
This can be used by userspace to map the OA reports received in the
i915 perf samples with their associated ctx's (The OA reports have the
hw ctx ID inform
From: Sourab Gupta
This series adds framework for collection of OA reports associated with the
render command stream, which are collected around batchbuffer boundaries.
Refloating the series rebased on Robert's latest patch set for
'Enabling OA unit for Gen 8 and 9 in i915 perf'
rm subsystem component.
> >
> > The patch series is being floated as RFC to gather feedback on the idea and
> > infrastructure proposed here and it's suitability to address the specific
> > problem statement/use case.
> >
> > v2: fix the bat failures caused due to miss
or states, memory stats, etc. can be move to this filesystem, if the
> >> idea introduced here is acceptable per se. The filesystem introduced is
> >> being used to house the data generated by i915 driver in this patch series,
> >> but will hopefully be generic eno
On Mon, 2016-12-12 at 07:33 -0800, Alex Deucher wrote:
> On Mon, Dec 12, 2016 at 1:14 AM, sourab gupta wrote:
> > On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote:
> >> From: Swati Dhingra
> >>
> >> Currently, we don't have a stable ABI which can
fic
> problem statement/use case.
>
> TODO: Create documentation. Will do so in next version.
>
> v2: fix the bat failures caused due to missing config check
>
> v3: Changes made:
> - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
> - Moving
commit message here and
> probably in the Kconfig help text as well.
>
>
> Matt
>
We've intended for drmfs to be ABI as Chris mentioned here:
https://lists.freedesktop.org/archives/intel-gfx/2016-December/113245.html
The intent is for drmfs to be a stable ABI for the fi
case of i915 driver, the top directory is created at
> > '/sys/kernel/drm/i915'.
> >
> > Signed-off-by: Sourab Gupta
> > Signed-off-by: Swati Dhingra
> > ---
> > drivers/gpu/drm/drm_drv.c | 22 ++
> > include/drm/drm_drv.
onstraints, there is a need for a new pseudo filesytem, customizable to DRM
> > specific requirements and catering to the needs to DRM subsystem components
> >
> > Signed-off-by: Sourab Gupta
> > Signed-off-by: Swati Dhingra
>
> I thought review feedback was to put
On Thu, 2016-12-01 at 00:15 -0800, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 12:32:32PM +0530, swati.dhin...@intel.com wrote:
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 84fcfcb..ead360bd 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/d
On Thu, 2016-12-01 at 00:11 -0800, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 12:32:31PM +0530, swati.dhin...@intel.com wrote:
> > diff --git a/fs/Kconfig b/fs/Kconfig
> > index 4bd03a2..7d0ac20 100644
> > --- a/fs/Kconfig
> > +++ b/fs/Kconfig
> > @@ -200,6 +200,15 @@ config HUGETLBFS
> > confi
On Thu, 2016-12-01 at 00:07 -0800, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 12:32:31PM +0530, swati.dhin...@intel.com wrote:
> > +int drmfs_init(void)
> > +{
> > + int retval;
> > +
> > + retval = sysfs_create_mount_point(kernel_kobj, "drm");
> > + if (retval)
> > + return -EIN
ructure fits quite well for these usecases. With Chris' comments
addressed, the patch can have my r-b.
Reviewed-by: Sourab Gupta
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, 2016-11-08 at 03:47 -0800, Robert Bragg wrote:
>
>
> On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta
> wrote:
> On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> > The maximum OA sampling frequency is now configurable via a
> >
> Signed-off-by: Robert Bragg
> Reviewed-by: Matthew Auld
> ---
Good summary of early challenges faced while adapting core perf.
Reviewed-by: Sourab Gupta
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> The maximum OA sampling frequency is now configurable via a
> dev.i915.oa_max_sample_rate sysctl parameter.
>
> Following the precedent set by perf's similar
> kernel.perf_event_max_sample_rate the default maximum rate is 10Hz
>
> Signe
.com/rib/gputop
> > gputop-data/oa-*.xml
> > scripts/i915-perf-kernelgen.py
>
> $ make -C gputop-data -f Makefile.xml SYSFS=0 WHITELIST=RenderBasic
>
> Signed-off-by: Robert Bragg
> Reviewed-by: Matthew Auld
> ---
Looks good.
Reviewed-by: Sourab Gupta
On Mon, 2016-11-07 at 03:10 -0800, Matthew Auld wrote:
> On 4 November 2016 at 09:30, wrote:
> > From: Sourab Gupta
> >
> > Add a compile time option for detecting the overflow condition of command
> > stream buffer, and not overwriting the old entries in such a c
From: Sourab Gupta
Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports or PIPE_CONTROL commands
inserted in the ring). This limits the ability to correlate these samples
with the system events. If we scale the GPU timestamps
From: Sourab Gupta
This patch enables userspace to specify tags (per workload), provided via
execbuffer ioctl, which could be added to OA reports, to help associate
reports with the corresponding workloads.
There may be multiple stages within a single context, from a userspace
perspective. An
From: Sourab Gupta
This adds support for populating the ctx id for the periodic OA reports
when requested through the corresponding property.
For Gen8, the OA reports itself have the ctx ID and it is the one programmed
into HW while submitting workloads. Thus it's retrieved from reports i
On Fri, 2016-11-04 at 06:19 -0700, Robert Bragg wrote:
>
>
> On Fri, Nov 4, 2016 at 8:59 AM, sourab gupta
> wrote:
> On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> > Adds base i915 perf infrastructure for Gen performance
> metrics.
>
From: Sourab Gupta
The OA reports contain the least significant 32 bits of the gpu timestamp.
This patch enables retrieval of the timestamp field from OA reports, to
forward as 64 bit raw gpu timestamps in the perf samples.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_drv.h | 1
From: Sourab Gupta
This patch adds support for opening multiple concurrent perf streams for
different gpu engines, while having the restriction to open only a single
stream open for a particular gpu engine.
This enables userspace client to open multiple streams, one per engine,
at any time to
From: Sourab Gupta
For the drivers to be able to use the cross timestamp framework,
they need the information of current clocksource being used by the
kernel timekeeping. This is needed since the callback given by driver
into the get_device_system_crosststamp(), in order to synchronously read
From: Sourab Gupta
Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports or PIPE_CONTROL commands
inserted in the ring). This limits the ability to correlate these samples
with the system events. If we scale the GPU timestamps
From: Sourab Gupta
Refloating the series rebased on Robert's latest patchset. Since Robert's
patches are being reviewed and this patch series extends his framework to
enable multiple concurrent streams to capture command stream based metrics,
it would be good to keep this work in p
From: Sourab Gupta
This patch introduces flags and adds support for having pid output with
the OA reports generated through the RCS commands.
When the stream is opened with pid sample type, the pid information is also
captured through the command stream samples and forwarded along with the
OA
From: Sourab Gupta
This patch adds support for capturing MMIO register values through
i915 perf interface.
The userspace can request upto 8 MMIO register values to be dumped.
The addresses of these registers can be passed through the corresponding
property 'value' field while opening
From: Sourab Gupta
Add a compile time option for detecting the overflow condition of command
stream buffer, and not overwriting the old entries in such a case.
Also, set a status flag to forward the overflow condition to userspace if
overflow is detected.
Signed-off-by: Sourab Gupta
From: Sourab Gupta
Exporting clocks_calc_mult_shift is helpful for drivers to calculate
the mult/shift values for their clocks, given their frequency.
This is particularly useful when such drivers may want to associate
timecounter/cyclecounter abstraction for their clock sources, in order
to use
From: Sourab Gupta
This patch exposes a new sample source field to userspace. This field can
be populated to specify the origin of the OA report.
For e.g. for internally triggerred reports (non MI_RPC reports), the RPT_ID
field has bitfields for specifying the origin such as timer, or render ctx
From: Sourab Gupta
When there are no pending CS OA samples, flush the periodic OA samples
collected so far.
We can safely forward the periodic OA samples in the case we
have no pending CS samples, but we can't do so in the case we have
pending CS samples, since we don't know what th
From: Sourab Gupta
This patch adds a new ctx getparam ioctl parameter, which can be used to
retrieve ctx unique id by userspace.
This can be used by userspace to map the i915 perf samples with their
particular ctx's, since those would be having ctx unique id's.
Otherwise the usersp
From: Sourab Gupta
This adds support for populating the ctx id for the periodic OA reports
when requested through the corresponding property.
For Gen8, the OA reports itself have the ctx ID and it is the one programmed
into HW while submitting workloads. Thus it's retrieved from reports i
From: Sourab Gupta
This patch extends the i915 perf framework to handle the perf sample
collection for any given gpu engine. Particularly, the support
for collecting timestamp sample type is added, which can be requested for
any engine.
With this, for RCS, timestamps and OA reports can be
From: Sourab Gupta
This patch enables userspace to specify tags (per workload), provided via
execbuffer ioctl, which could be added to OA reports, to help associate
reports with the corresponding workloads.
There may be multiple stages within a single context, from a userspace
perspective. An
From: Sourab Gupta
This patch introduces a framework to enable OA counter reports associated
with Render command stream. We can then associate the reports captured
through this mechanism with their corresponding context id's. This can be
further extended to associate any other met
gt; Signed-off-by: Robert Bragg
> Reviewed-by: Matthew Auld
Seems reasonable.
Reviewed-by: Sourab Gupta
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
dev_priv->perf.oa.n_builtin_sets =
> i915_oa_n_builtin_metric_sets_hsw;
>
> + dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
> +
> dev_priv->perf.initialized = true;
> }
>
> @@ -1492,6 +1538,8 @@ void i915_perf_fini(
ata/oa-*.xml
> > scripts/i915-perf-kernelgen.py
>
> $ make -C gputop-data -f Makefile.xml SYSFS=1 WHITELIST=RenderBasic
>
> Signed-off-by: Robert Bragg
> Reviewed-by: Matthew Auld
Looks good to me.
Reviewed-by: Sourab Gupta
___
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system
ey attempt an OACONTROL write.
>
> This bumps the command parser version from 7 to 8, as the change is
> visible to userspace.
>
> Signed-off-by: Robert Bragg
> Reviewed-by: Matthew Auld
Well, looks reasonable to me.
Reviewed-by: Sourab Gupta
_
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> OACONTROL changes quite a bit for gen8, with some bits split out into a
> per-context OACTXCONTROL register. Rename now before adding more gen7 OA
> registers
>
> Signed-off-by: Robert Bragg
> Reviewed-by: Matthew Auld
R
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> The minimal sampling period is now configurable via a
> dev.i915.oa_min_timer_exponent sysctl parameter.
>
> Following the precedent set by perf, the default is the minimum that
> won't (on its own) exceed the default kernel.perf_event_max_s
On Thu, 2016-06-02 at 11:30 +0530, Martin Peres wrote:
> On 02/06/16 08:18, sourab.gu...@intel.com wrote:
> > From: Sourab Gupta
> >
> > This patch introduces a framework to enable OA counter reports associated
> > with Render command stream. We can then associate the r
From: Sourab Gupta
Add a compile time option for detecting the overflow condition of command
stream buffer, and not overwriting the old entries in such a case.
Also, set a status flag to forward the overflow condition to userspace if
overflow is detected.
Signed-off-by: Sourab Gupta
From: Sourab Gupta
This series adds framework for collection of gpu performance metrics
associated with the command stream of a particular engine. These metrics
include OA reports, timestamps, mmio metrics, etc. These metrics are
are collected around batchbuffer boundaries.
This work utilizes
From: Sourab Gupta
This patch exposes a new sample source field to userspace. This field can
be populated to specify the origin of the OA report.
For e.g. for internally triggerred reports (non MI_RPC reports), the RPT_ID
field has bitfields for specifying the origin such as timer, or render ctx
From: Sourab Gupta
This patch adds support for opening multiple concurrent perf streams for
different gpu engines, while having the restriction to open only a single
stream open for a particular gpu engine.
This enables userspace client to open multiple streams, one per engine,
at any time to
From: Sourab Gupta
This patch enables userspace to specify tags (per workload), provided via
execbuffer ioctl, which could be added to OA reports, to help associate
reports with the corresponding workloads.
There may be multiple stages within a single context, from a userspace
perspective. An
From: Sourab Gupta
Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports or PIPE_CONTROL commands
inserted in the ring). This limits the ability to correlate these samples
with the system events. If we scale the GPU timestamps
From: Sourab Gupta
The OA reports contain the least significant 32 bits of the gpu timestamp.
This patch enables retrieval of the timestamp field from OA reports, to
forward as 64 bit raw gpu timestamps in the perf samples.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_drv.h | 1
From: Sourab Gupta
This patch adds support for capturing MMIO register values through
i915 perf interface.
The userspace can request upto 8 MMIO register values to be dumped.
The addresses of these registers can be passed through the corresponding
property 'value' field while opening
From: Sourab Gupta
For the drivers to be able to use the cross timestamp framework,
they need the information of current clocksource being used by the
kernel timekeeping. This is needed since the callback given by driver
into the get_device_system_crosststamp(), in order to synchronously read
From: Sourab Gupta
Exporting clocks_calc_mult_shift is helpful for drivers to calculate
the mult/shift values for their clocks, given their frequency.
This is particularly useful when such drivers may want to associate
timecounter/cyclecounter abstraction for their clock sources, in order
to use
From: Sourab Gupta
This patch introduces a framework to enable OA counter reports associated
with Render command stream. We can then associate the reports captured
through this mechanism with their corresponding context id's. This can be
further extended to associate any other met
From: Sourab Gupta
When there are no pending CS OA samples, flush the periodic OA samples
collected so far.
We can safely forward the periodic OA samples in the case we
have no pending CS samples, but we can't do so in the case we have
pending CS samples, since we don't know what th
From: Sourab Gupta
This adds support for populating the ctx id for the periodic OA reports
when requested through the corresponding property.
For Gen8, the OA reports itself have the ctx ID and it is the one programmed
into HW while submitting workloads. Thus it's retrieved from reports i
From: Sourab Gupta
This patch adds a new ctx getparam ioctl parameter, which can be used to
retrieve ctx unique id by userspace.
This can be used by userspace to map the i915 perf samples with their
particular ctx's, since those would be having ctx unique id's.
Otherwise the usersp
From: Sourab Gupta
This patch extends the i915 perf framework to handle the perf sample
collection for any given gpu engine. Particularly, the support
for collecting timestamp sample type is added, which can be requested for
any engine.
With this, for RCS, timestamps and OA reports can be
From: Sourab Gupta
This patch introduces flags and adds support for having pid output with
the OA reports generated through the RCS commands.
When the stream is opened with pid sample type, the pid information is also
captured through the command stream samples and forwarded along with the
OA
On Sat, 2016-04-23 at 01:19 +0530, Chris Wilson wrote:
> On Fri, Apr 22, 2016 at 05:04:04PM +0530, sourab.gu...@intel.com wrote:
> > +static u64 get_current_gpu_ts(struct drm_i915_private *dev_priv)
> > +{
> > + return ((u64)I915_READ(GT_TIMESTAMP_COUNT_UDW) << 32) |
> > + I915_READ(GT
From: Sourab Gupta
This patch adds support for capturing MMIO register values through
i915 perf interface.
The userspace can request upto 8 MMIO register values to be dumped.
The addresses of these registers can be passed through the corresponding
property 'value' field while opening
From: Sourab Gupta
Add a compile time option for detecting the overflow condition of command
stream buffer, and not overwriting the old entries in such a case.
Also, set a status flag to forward the overflow condition to userspace if
overflow is detected.
Signed-off-by: Sourab Gupta
From: Sourab Gupta
The OA reports contain the least significant 32 bits of the gpu timestamp.
This patch enables retrieval of the timestamp field from OA reports, to
forward as 64 bit raw gpu timestamps in the perf samples.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_drv.h | 1
From: Sourab Gupta
Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports or PIPE_CONTROL commands
inserted in the ring). This limits the ability to correlate these samples
with the system events. If we scale the GPU timestamps
From: Sourab Gupta
This adds support for populating the ctx id for the periodic OA reports
when requested through the corresponding property.
For Gen8, the OA reports itself have the ctx ID and it is the one programmed
into HW while submitting workloads. Thus it's retrieved from reports i
From: Sourab Gupta
This patch extends the i915 perf framework to handle the perf sample
collection for any given gpu engine. Particularly, the support
for collecting timestamp sample type is added, which can be requested for
any engine.
With this, for RCS, timestamps and OA reports can be
From: Sourab Gupta
When there are no pending CS OA samples, flush the periodic OA samples
collected so far.
We can safely forward the periodic OA samples in the case we
have no pending CS samples, but we can't do so in the case we have
pending CS samples, since we don't know what th
From: Sourab Gupta
This patch enables userspace to specify tags (per workload), provided via
execbuffer ioctl, which could be added to OA reports, to help associate
reports with the corresponding workloads.
There may be multiple stages within a single context, from a userspace
perspective. An
From: Sourab Gupta
This patch introduces a framework to enable OA counter reports associated
with Render command stream. We can then associate the reports captured
through this mechanism with their corresponding context id's. This can be
further extended to associate any other met
From: Sourab Gupta
This patch introduces flags and adds support for having pid output with
the OA reports generated through the RCS commands.
When the stream is opened with pid sample type, the pid information is also
captured through the command stream samples and forwarded along with the
OA
From: Sourab Gupta
This patch adds support for opening multiple concurrent perf streams for
different gpu engines, while having the restriction to open only a single
stream open for a particular gpu engine.
This enables userspace client to open multiple streams, one per engine,
at any time to
From: Sourab Gupta
This series adds framework for collection of gpu performance metrics
associated with the command stream of a particular engine. These metrics
include OA reports, timestamps, mmio metrics, etc. These metrics are
are collected around batchbuffer boundaries.
This work utilizes
From: Sourab Gupta
This patch exposes a new sample source field to userspace. This field can
be populated to specify the origin of the OA report.
For e.g. for internally triggerred reports (non MI_RPC reports), the RPT_ID
field has bitfields for specifying the origin such as timer, or render ctx
From: Sourab Gupta
The current context user handles are specific to drm file instance.
There are some usecases, which may require a global id for the contexts.
For e.g. a system level GPU profiler tool may lean upon the global context
ids to associate the performance snapshots with individual
From: Robert Bragg
This will allow the ID to be given to the HW as the unique context
identifier that's written, for example, to the context status buffer
on preemption and included in reports written by the OA unit.
Cc: Sourab Gupta
Signed-off-by: Robert Bragg
---
drivers/gpu/drm
D and we want to be able to accurately filter
reports for a specific context, ideally without the added complexity of
tracking context re-pinning while the OA buffer may contain reports with
older IDs.
Cc: Sourab Gupta
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_debugfs.c
1 - 100 of 252 matches
Mail list logo
