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 <sagar.a.kam...@intel.com>
> wrote:
>
>>
>>
>> -
On Thu, 2017-03-16 at 05:59 -0700, Robert Bragg wrote:
> On Thu, Mar 16, 2017 at 6:14 AM, <sourab.gu...@intel.com> wrote:
> > From: Sourab Gupta <sourab.gu...@intel.com>
> >
> > This series adds framework for collection of OA reports associated with the
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 <sourab.gu...@intel.com>
> >
> > This patch extends the i915 perf framework to handle the perf sample
> > co
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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'
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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, o
From: Sourab Gupta <sourab.gu...@intel.com>
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 <
From: Sourab Gupta <sourab.gu...@intel.com>
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, time
From: Sourab Gupta <sourab.gu...@intel.com>
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 s
From: Sourab Gupta <sourab.gu...@intel.com>
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. Thu
From: Sourab Gupta <sourab.gu...@intel.com>
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 associa
From: Sourab Gupta <sourab.gu...@intel.com>
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 statu
From: Sourab Gupta <sourab.gu...@intel.com>
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 rig
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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 s
From: Sourab Gupta <sourab.gu...@intel.com>
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: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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
ing 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 missing config check
> >
> > v3: Changes made:
&
. 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 enough to provide scope for usage by
On Mon, 2016-12-12 at 07:33 -0800, Alex Deucher wrote:
> On Mon, Dec 12, 2016 at 1:14 AM, sourab gupta <sourab.gu...@intel.com> wrote:
> > On Mon, 2016-12-05 at 03:06 -0800, Dhingra, Swati wrote:
> >> From: Swati Dhingra <swati.dhin...@intel.com>
> >>
>
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 config checks to header (Chris,Da
essage 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 files it's holdin
rectory directly.
> > In case of i915 driver, the top directory is created at
> > '/sys/kernel/drm/i915'.
> >
> > Signed-off-by: Sourab Gupta <sourab.gu...@intel.com>
> > Signed-off-by: Swati Dhingra <swati.dhin...@intel.com>
> > ---
> > d
t; constraints, 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 <sourab.gu...@intel.com>
> > Signed-off-by: Swati Dhingra <swati.dhin.
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
> > +++
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
> >
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
e some time on extending the interfaces per
the usecase of multiple concurrent streams (on different engines), and
infrastructure fits quite well for these usecases. With Chris' comments
addressed, the patch can have my r-b.
Reviewed-by: Sourab Gupta <sourab.gu...@intel.com>
__
On Tue, 2016-11-08 at 03:47 -0800, Robert Bragg wrote:
>
>
> On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta <sourab.gu...@intel.com>
> wrote:
> On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote:
> > The maximum OA sampling freque
on <ch...@chris-wilson.co.uk>
> Signed-off-by: Robert Bragg <rob...@sixbynine.org>
> Reviewed-by: Matthew Auld <matthew.a...@intel.com>
> ---
Good summary of early challenges faced while adapting core perf.
Reviewed-by: Sourab Gupta <sourab.gu...@intel.com>
_
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
>
>
.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 <rob...@sixbynine.org>
> Reviewed-by: Matthew Auld <matthew.a...@intel.com>
On Mon, 2016-11-07 at 03:10 -0800, Matthew Auld wrote:
> On 4 November 2016 at 09:30, <sourab.gu...@intel.com> wrote:
> > From: Sourab Gupta <sourab.gu...@intel.com>
> >
> > Add a compile time option for detecting the overflow condition of command
> > str
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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: Sourab Gupta <sourab.gu...@intel.com>
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. Thu
On Fri, 2016-11-04 at 06:19 -0700, Robert Bragg wrote:
>
>
> On Fri, Nov 4, 2016 at 8:59 AM, sourab gupta <sourab.gu...@intel.com>
> wrote:
> On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> > Adds base i915 perf infrastructure for Gen pe
From: Sourab Gupta <sourab.gu...@intel.com>
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 <
From: Sourab Gupta <sourab.gu...@intel.com>
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, o
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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 t
From: Sourab Gupta <sourab.gu...@intel.com>
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 s
From: Sourab Gupta <sourab.gu...@intel.com>
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'
From: Sourab Gupta <sourab.gu...@intel.com>
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.
Sign
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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.
Oth
From: Sourab Gupta <sourab.gu...@intel.com>
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. Thu
From: Sourab Gupta <sourab.gu...@intel.com>
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, time
From: Sourab Gupta <sourab.gu...@intel.com>
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 associa
ed-off-by: Robert Bragg <rob...@sixbynine.org>
> Reviewed-by: Matthew Auld <matthew.a...@intel.com>
Seems reasonable.
Reviewed-by: Sourab Gupta <sourab.gu...@intel.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_private *dev_priv)
> 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 i
ml
> > scripts/i915-perf-kernelgen.py
>
> $ make -C gputop-data -f Makefile.xml SYSFS=1 WHITELIST=RenderBasic
>
> Signed-off-by: Robert Bragg <rob...@sixbynine.org>
> Reviewed-by: Matthew Auld <matthew.a...@intel.com>
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
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 <rob...@sixbynine.org>
> Reviewed-by: Matthew Auld <matthew.a...@intel.com>
Well, looks reasonable to me.
Reviewed-by:
gt; Reviewed-by: Matthew Auld <matthew.a...@intel.com>
Reviewed-by: Sourab Gupta <sourab.gu...@intel.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
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 <sourab.gu...@intel.com>
> >
> > This patch introduces a framework to enable OA counter reports associated
> > with Render comm
From: Sourab Gupta <sourab.gu...@intel.com>
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.
Sign
From: Sourab Gupta <sourab.gu...@intel.com>
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 batch
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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, o
From: Sourab Gupta <sourab.gu...@intel.com>
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: Sourab Gupta <sourab.gu...@intel.com>
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 <
From: Sourab Gupta <sourab.gu...@intel.com>
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'
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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 associa
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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. Thu
From: Sourab Gupta <sourab.gu...@intel.com>
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.
Oth
From: Sourab Gupta <sourab.gu...@intel.com>
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, time
From: Sourab Gupta <sourab.gu...@intel.com>
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 s
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) |
> > +
From: Sourab Gupta <sourab.gu...@intel.com>
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'
From: Sourab Gupta <sourab.gu...@intel.com>
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, time
From: Sourab Gupta <sourab.gu...@intel.com>
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.
Sign
From: Sourab Gupta <sourab.gu...@intel.com>
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 <
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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. Thu
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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: Sourab Gupta <sourab.gu...@intel.com>
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 associa
From: Sourab Gupta <sourab.gu...@intel.com>
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 s
From: Sourab Gupta <sourab.gu...@intel.com>
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, o
From: Sourab Gupta <sourab.gu...@intel.com>
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 batch
From: Sourab Gupta <sourab.gu...@intel.com>
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
From: Sourab Gupta <sourab.gu...@intel.com>
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 perfo
From: Robert Bragg <rob...@sixbynine.org>
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 <sourab.gu...@intel.com>
buffer tagged with this ID 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 <sourab.gu...@intel.com>
Signed-off-by: Rober
From: Sourab Gupta <sourab.gu...@intel.com>
This patch adds a new ctx getparam ioctl parameter, which can be used to
retrieve ctx global_id for any particular ctx by userspace.
This can be used by userspace to map the i915 perf samples with their
particular ctx's, since those would be havi
1 - 100 of 247 matches
Mail list logo
