On Tue, 03 Mar 2020 14:19:04 -0800, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> This let's the application choose to be driven by the interrupt
> mechanism of the HW. In conjuction with long periods for checks for
> the availability of data on the CPU, this can reduce the CPU
On Tue, 03 Mar 2020 14:19:05 -0800, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> With the currently available parameters for the i915-perf stream,
> there are still situations that are not well covered :
>
> If an application opens the stream with polling disable or at very low
>
On Wed, 04 Mar 2020 00:52:34 -0800, Lionel Landwerlin wrote:
>
> On 04/03/2020 07:48, Dixit, Ashutosh wrote:
> > On Tue, 03 Mar 2020 14:19:05 -0800, Umesh Nerlige Ramappa wrote:
> >> From: Lionel Landwerlin
> >>
> >> With the currently availa
On Tue, 10 Mar 2020 13:44:30 -0700, Lionel Landwerlin wrote:
>
> On 09/03/2020 21:51, Umesh Nerlige Ramappa wrote:
> > On Wed, Mar 04, 2020 at 09:56:28PM -0800, Dixit, Ashutosh wrote:
> >> On Wed, 04 Mar 2020 00:52:34 -0800, Lionel Landwerlin wrote:
> >>>
> >
On Tue, 03 Mar 2020 14:19:02 -0800, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> This new parameter let's the application choose how often the OA
> buffer should be checked on the CPU side for data availability. Longer
> polling period tend to reduce CPU overhead if the
On Thu, 12 Mar 2020 13:37:12 -0700, Lionel Landwerlin wrote:
> On 12/03/2020 21:27, Dixit, Ashutosh wrote:
> > On Tue, 03 Mar 2020 14:19:02 -0800, Umesh Nerlige Ramappa wrote:
> >> From: Lionel Landwerlin
> >>
> >> This new parameter let's the application
On Wed, 08 Apr 2020 13:59:38 -0700, Rodrigo Vivi wrote:
>
> Hi Ashutosh and Chris,
>
> these patches seems needed for 5.7 but didn't applied cleanly on dinf:
>
> Failed to cherry-pick:
> 6352219c39c0 ("drm/i915/perf: Do not clear pollin for small user read
> buffers")
> 614654abe847 ("drm/i915:
On Tue, 14 Apr 2020 12:05:09 -0700, Chris Wilson wrote:
>
> The poll() is proving unreliable, where our tests timeout without the
> spinner being terminated. Let's try a blocking read instead!
Weird, wondering if all we need to do is set TFD_NONBLOCK on the fd?
>
> Closes:
On Tue, 14 Apr 2020 09:59:48 -0700, Umesh Nerlige Ramappa wrote:
> On Mon, Apr 13, 2020 at 11:58:18PM -0700, Dixit, Ashutosh wrote:
> > On Mon, 13 Apr 2020 22:08:47 -0700, Dixit, Ashutosh wrote:
> >>
> >> On Mon, 13 Apr 2020 08:48:20 -0700, Umesh Nerlige Ramappa wrote
On Tue, 14 Apr 2020 12:09:42 -0700, Dixit, Ashutosh wrote:
>
> On Tue, 14 Apr 2020 09:59:48 -0700, Umesh Nerlige Ramappa wrote:
> > On Mon, Apr 13, 2020 at 11:58:18PM -0700, Dixit, Ashutosh wrote:
> > > On Mon, 13 Apr 2020 22:08:47 -0700, Dixit, Ashutosh wrote:
> > >&
On Mon, 13 Apr 2020 08:48:22 -0700, Umesh Nerlige Ramappa wrote:
>
> @@ -556,16 +559,23 @@ static bool oa_buffer_check_unlocked(struct
> i915_perf_stream *stream)
> * waiting on an event to occur. These checks are redundant when hrtimer
> events
> * will call oa_buffer_check_unlocked to
On Mon, 13 Apr 2020 08:48:21 -0700, Umesh Nerlige Ramappa wrote:
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index 0cc7dd54f4f9..61eee9fb8872 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++
On Mon, 13 Apr 2020 22:08:47 -0700, Dixit, Ashutosh wrote:
>
> On Mon, 13 Apr 2020 08:48:20 -0700, Umesh Nerlige Ramappa wrote:
> >
> > A condition in wait_event_interruptible seems to be checked twice before
> > waiting on the event to occur. These checks are redundant
On Mon, 13 Apr 2020 08:48:20 -0700, Umesh Nerlige Ramappa wrote:
>
> A condition in wait_event_interruptible seems to be checked twice before
> waiting on the event to occur. These checks are redundant when hrtimer
> events will call oa_buffer_check_unlocked to update the oa_buffer tail
>
On Wed, 25 Mar 2020 12:25:59 -0700, Lionel Landwerlin wrote:
>
> On 25/03/2020 20:20, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
On Wed, 25 Mar 2020 17:32:35 -0700, Umesh Nerlige Ramappa wrote:
>
> On Wed, Mar 25, 2020 at 11:20:19AM -0700, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous
On Thu, 26 Mar 2020 02:09:34 -0700, Lionel Landwerlin wrote:
>
> On 26/03/2020 06:43, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
On Thu, 26 Mar 2020 11:02:46 -0700, Umesh Nerlige Ramappa wrote:
> On Wed, Mar 25, 2020 at 06:52:52PM -0700, Dixit, Ashutosh wrote:
> > On Wed, 25 Mar 2020 17:32:35 -0700, Umesh Nerlige Ramappa wrote:
> >>
> >> On Wed, Mar 25, 2020 at 11:20:19AM
On Fri, 03 Apr 2020 09:17:14 -0700, Chris Wilson wrote:
>
> Quoting Ashutosh Dixit (2020-04-03 02:01:20)
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
On Mon, 30 Mar 2020 01:23:29 -0700, Lionel Landwerlin wrote:
>
> On 28/03/2020 01:16, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
On Mon, 30 Mar 2020 09:38:23 -0700, Chris Wilson wrote:
>
> Quoting Dixit, Ashutosh (2020-03-30 16:55:32)
> > On Mon, 30 Mar 2020 03:09:20 -0700, Chris Wilson wrote:
> > >
> > > Quoting Lionel Landwerlin (2020-03-30 10:14:11)
> > > > Reading or wri
On Tue, 31 Mar 2020 00:34:10 -0700, Lionel Landwerlin wrote:
>
> On 31/03/2020 08:22, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
On Tue, 31 Mar 2020 23:57:57 -0700, Lionel Landwerlin wrote:
>
> On 01/04/2020 02:14, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
On Mon, 30 Mar 2020 03:09:20 -0700, Chris Wilson wrote:
>
> Quoting Lionel Landwerlin (2020-03-30 10:14:11)
> > Reading or writing those fields should only happen under
> > stream->oa_buffer.ptr_lock.
>
> Writing, yes. Reading as a pair, sure. There are other ways you can
> ensure that the
Chris Wilson
> Cc: "Dixit, Ashutosh"
Reviewed-by: Ashutosh Dixit
> ---
> lib/igt_dummyload.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index 99ca84ad8..ae0fb9378 100644
> -
Discussed with Umesh today. Below is what we came up with.
On Tue, 17 Mar 2020 17:03:30 -0700, Lionel Landwerlin wrote:
> On 16/03/2020 21:23, Dixit, Ashutosh wrote:
> > On Thu, 12 Mar 2020 16:04:59 -0700, Umesh Nerlige Ramappa wrote:
> >> From: Lionel Landwerlin
>
On Thu, 12 Mar 2020 16:05:02 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> This new parameter let's the application choose how often the OA
> buffer should be checked on the CPU side for data availability. Longer
> polling period tend to reduce CPU overhead if the
On Thu, 19 Mar 2020 15:52:03 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> This new parameter let's the application choose how often the OA
> buffer should be checked on the CPU side for data availability. Longer
> polling period tend to reduce CPU overhead if the
On Thu, 19 Mar 2020 15:52:01 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> We're about to introduce an options to open the perf stream, giving
> the user ability to configure how often it wants the kernel to poll
> the OA registers for available data.
>
> Right now the
On Sat, 21 Mar 2020 16:26:42 -0700, Dixit, Ashutosh wrote:
>
> On Thu, 19 Mar 2020 15:52:01 -0700, Umesh Nerlige Ramappa wrote:
> >
> > From: Lionel Landwerlin
>
> > @@ -477,16 +468,6 @@ static bool oa_buffer_check_unlocked(struct
&
On Sat, 21 Mar 2020 21:44:43 -0700, Dixit, Ashutosh wrote:
>
> Actually a couple of further improvements to the loop above are
> possible. First there is no reason to start at previous_tail, we can just
> start at the aligned hw_tail itself.
Unless we deliberately want to wait and del
On Thu, 12 Mar 2020 16:05:00 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> This isn't really gen specific stuff, so just move it to the common
> code.
It seems pollin is not the only member which is not gen specific but is
initialized in gen specific code. Anyway any other
On Thu, 12 Mar 2020 16:04:59 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> We're about to introduce an options to open the perf stream, giving
> the user ability to configure how often it wants the kernel to poll
> the OA registers for available data.
>
> Right now the
On Thu, 12 Mar 2020 16:05:01 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> The only bit of the status register we currently report in the
> i915-perf stream is the "report loss" bit. Only report this when we
> have some data to report with it. There was a kind of
On Tue, 24 Mar 2020 11:54:55 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> We're about to introduce an options to open the perf stream, giving
> the user ability to configure how often it wants the kernel to poll
> the OA registers for available data.
>
> Right now the
On Fri, 28 Aug 2020 06:31:25 -0700, Lionel Landwerlin wrote:
>
> I'll need this in IGT to identify the different kind of GTs and apply
> the right performance query configuration.
Reviewed-by: Ashutosh Dixit
> Signed-off-by: Lionel Landwerlin
> ---
> include/drm/i915_pciids.h | 14
On Fri, 13 Nov 2020 14:12:09 -0800, Umesh Nerlige Ramappa wrote:
>
> > + if (wal->engine)
> > + spin_lock_irqsave(>engine->uncore->lock, flags);
> > +
> > + kfree(wal->list);
>
> if (wal->list)
> kfree(wal->list);
void kfree(const void *objp)
{
...
if
On Wed, 04 Nov 2020 16:21:24 -0800, Chris Wilson wrote:
>
> Use gem_reopen_driver() to always reopen the same device without relying
> on the filtering in drm_open_driver().
Reviewed-by: Ashutosh Dixit
> Signed-off-by: Chris Wilson
> ---
> tests/i915/gem_ctx_thrash.c | 2 +-
> 1 file changed,
On Wed, 04 Nov 2020 16:21:23 -0800, Chris Wilson wrote:
>
> Reopen the existing device, rather than relying on the filtering in
> drm_open_driver().
Reviewed-by: Ashutosh Dixit
> Signed-off-by: Chris Wilson
> ---
> tests/i915/gem_exec_whisper.c | 8
> 1 file changed, 4 insertions(+),
On Wed, 04 Nov 2020 14:23:21 -0800, Chris Wilson wrote:
>
> Avoid any unnecessary filtering inside drm_open_driver() by explicitly
> reopening the same device.
>
> Signed-off-by: Chris Wilson
> ---
> tests/i915/gem_exec_parallel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Sun, 09 May 2021 16:11:43 -0700, Jason Ekstrand wrote:
>
> Yes, landing GuC support may be the first step in removing execlist
> support. The inevitable reality is that GPU scheduling is coming and
> likely to be there only path in the not-too-distant future. (See also
> the ongoing thread
On Mon, 24 May 2021 07:38:01 -0700, Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin
>
> Test incorrectly assumes no modparam means default expiry, while in
> reality no modparam means old kernel / de-selected feature in which
> case test should skip.
>
> v2:
> * New line. (Petri)
Reviewed-by:
On Fri, 30 Apr 2021 16:00:46 -0700, Dixit, Ashutosh wrote:
>
> On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
> >
> > Looks like the engine can be dropped since all timestamps are in sync. I
> > just have one more question here. The timestamp it
On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
>
> Looks like the engine can be dropped since all timestamps are in sync. I
> just have one more question here. The timestamp itself is 36 bits. Should
> the uapi also report the timestamp width to the user OR should I just
>
On Fri, 30 Apr 2021 19:19:59 -0700, Umesh Nerlige Ramappa wrote:
>
> On Fri, Apr 30, 2021 at 07:35:41PM -0500, Jason Ekstrand wrote:
> > On April 30, 2021 18:00:58 "Dixit, Ashutosh"
> > wrote:
> >
> > On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Ne
On Sat, 23 Jan 2021 05:05:02 -0800, Patchwork wrote:
>
> [1 ]
> [2 ]
> Project List - Patchwork
>
> Patch Details
>
> Series: drm/i915: Start disabling pread/pwrite ioctl's for future platforms
> URL: https://patchwork.freedesktop.org/series/86199/
> State: failure
> Details:
On Thu, 11 Mar 2021 14:36:31 -0800, Matt Roper wrote:
>
> From: Umesh Nerlige Ramappa
>
> Enable relevant OA formats for ADL_P.
Reviewed-by: Ashutosh Dixit
> Cc: Ashutosh Dixit
> Signed-off-by: Umesh Nerlige Ramappa
> Signed-off-by: Clinton Taylor
> Signed-off-by: Matt Roper
> ---
>
On Mon, 15 Mar 2021 07:34:25 -0700, Jason Ekstrand wrote:
>
> These three patches exist to clean up some of our IOCTL mess in i915.
> We've got more clean-up we should do eventually, but these are some of the
> easiest to drop and most egregious cases.
>
> Test-with:
On Thu, 11 Mar 2021 12:20:17 -0800, Jason Ekstrand wrote:
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b2e3b5cfccb4a..78ad5a9dd4784 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -374,10 +374,19 @@ int
>
On Wed, 10 Mar 2021 13:00:49 -0800, Jason Ekstrand wrote:
>
> libdrm has supported the newer execbuffer2 ioctl and using it by default
> when it exists since libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22
> which landed Mar 2, 2010. The i915 and i965 drivers in Mesa at the time
> both
On Thu, 11 Mar 2021 20:31:33 -0800, Jason Ekstrand wrote:
> On March 11, 2021 20:26:06 "Dixit, Ashutosh" wrote:
> On Wed, 10 Mar 2021 13:00:49 -0800, Jason Ekstrand wrote:
>
> libdrm has supported the newer execbuffer2 ioctl and using it by default
> when it e
On Mon, 01 Mar 2021 16:01:41 -0800, Nerlige Ramappa, Umesh wrote:
>
> SAMPLE_OA parameter enables sampling of OA buffer and results in a call
> to init the OA buffer which initializes the OA unit head/tail pointers.
> The OA_EXPONENT parameter controls the periodicity of the OA reports in
> the OA
On Wed, 28 Jul 2021 15:20:15 -0700, Dixit, Ashutosh wrote:
>
> On Wed, 28 Jul 2021 03:30:31 -0700, Matthew Auld wrote:
> >
> > diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> > index 4b4f2114..e2514f0c 100644
> > --- a/lib/i915/gem_mman.c
> > +++
On Wed, 28 Jul 2021 03:30:33 -0700, Matthew Auld wrote:
>
> diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> index 222e8896..337d28fb 100644
> --- a/lib/i915/gem_mman.c
> +++ b/lib/i915/gem_mman.c
> @@ -580,6 +580,8 @@ void *gem_mmap__cpu_coherent(int fd, uint32_t handle,
> uint64_t
On Wed, 28 Jul 2021 03:30:31 -0700, Matthew Auld wrote:
>
> diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> index 4b4f2114..e2514f0c 100644
> --- a/lib/i915/gem_mman.c
> +++ b/lib/i915/gem_mman.c
> @@ -497,6 +497,43 @@ void *gem_mmap_offset__cpu(int fd, uint32_t handle,
> uint64_t
On Wed, 28 Jul 2021 03:30:32 -0700, Matthew Auld wrote:
>
> diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> index e2514f0c..222e8896 100644
> --- a/lib/i915/gem_mman.c
> +++ b/lib/i915/gem_mman.c
> @@ -383,9 +383,10 @@ void *__gem_mmap__device_coherent(int fd, uint32_t
> handle, uint64_t
On Wed, 28 Jul 2021 03:30:34 -0700, Matthew Auld wrote:
>
> diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> index 337d28fb..6f5e6d72 100644
> --- a/lib/i915/gem_mman.c
> +++ b/lib/i915/gem_mman.c
> @@ -434,7 +434,13 @@ void *gem_mmap__device_coherent(int fd, uint32_t handle,
> uint64_t
On Fri, 30 Jul 2021 01:53:46 -0700, Matthew Auld wrote:
>
> The set_caching ioctl is gone for discrete, and now just returns
> -ENODEV. Update the gem_sanitycheck to account for that. After this we
> should be back to just having the breakage caused by missing reloc
> support for the reload
On Fri, 30 Jul 2021 01:53:45 -0700, Matthew Auld wrote:
>
> On discrete set_domain is now gone, instead we just need to add the
> wait.
Reviewed-by: Ashutosh Dixit
> Signed-off-by: Matthew Auld
> Cc: Maarten Lankhorst
> Cc: Ashutosh Dixit
> Cc: Daniel Vetter
> Cc: Ramalingam C
> ---
>
On Thu, 29 Jul 2021 01:50:45 -0700, Matthew Auld wrote:
>
Hi Matt,
> On 29/07/2021 00:07, Dixit, Ashutosh wrote:
> > On Wed, 28 Jul 2021 03:30:34 -0700, Matthew Auld wrote:
> >>
> >> diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> >> index 337d28
On Fri, 30 Jul 2021 01:53:40 -0700, Matthew Auld wrote:
>
> On discrete we only support the new fixed mode.
>
> Signed-off-by: Matthew Auld
> Cc: Maarten Lankhorst
> Cc: Ashutosh Dixit
> Cc: Daniel Vetter
> Cc: Ramalingam C
> ---
> lib/i915/gem_mman.c | 8 +++-
> 1 file changed, 7
On Tue, 27 Jul 2021 23:08:40 -0700, Petri Latvala wrote:
>
> On Tue, Jul 27, 2021 at 07:01:24PM -0700, Dixit, Ashutosh wrote:
> > On Mon, 26 Jul 2021 05:03:04 -0700, Matthew Auld wrote:
> > >
> > > diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> &g
On Wed, 13 Oct 2021 15:43:17 -0700, wrote:
>
> From: John Harrison
>
> The gem_exec_fair test is specifically testing scheduler algorithm
> performance. However, GuC does not implement the same algorithm as
> execlist mode and this test is not applicable. So, until sw arch
> approves a new
On Wed, 13 Oct 2021 18:07:05 -0700, John Harrison wrote:
>
> On 10/13/2021 15:53, Dixit, Ashutosh wrote:
> >> diff --git a/tests/i915/gem_exec_fair.c b/tests/i915/gem_exec_fair.c
> >> index ef5a450f6..ca9c73c6e 100644
> >> --- a/tests/i915/gem_exec_fair.c
>
On Thu, 21 Oct 2021 05:53:31 -0700, Matthew Auld wrote:
>
> wbinvd_on_all_cpus() is only defined on x86 it seems, plus we need to
> include asm/smp.h here.
Reviewed-by: Ashutosh Dixit
> Reported-by: kernel test robot
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
>
On Fri, 15 Oct 2021 14:54:34 -0700, wrote:
>
> diff --git a/tests/i915/gem_exec_fair.c b/tests/i915/gem_exec_fair.c
> index ef5a450f6..5cbb48f5a 100644
> --- a/tests/i915/gem_exec_fair.c
> +++ b/tests/i915/gem_exec_fair.c
> @@ -1314,6 +1314,12 @@ igt_main
>
On Fri, 15 Oct 2021 14:46:20 -0700, John Harrison wrote:
>
> On 10/15/2021 07:52, Dixit, Ashutosh wrote:
> > On Thu, 14 Oct 2021 12:42:38 -0700, wrote:
> >> + /*
> >> + * These tests are for a specific scheduling model which is
> >>
On Thu, 14 Oct 2021 12:42:38 -0700, wrote:
>
> + /*
> + * These tests are for a specific scheduling model which is
> + * not currently implemented by GuC. So skip on GuC platforms.
> + */
> + devid = intel_get_drm_devid(i915);
> +
On Fri, 03 Dec 2021 07:54:56 -0800, Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin
>
> Use the i915 exported data in /proc//fdinfo to show GPU utilization
> per DRM client.
Didn't we just remove it? Adding it back now? Sorry for the probably dumb
question :/
On Mon, 06 Dec 2021 16:45:42 -0800, Umesh Nerlige Ramappa wrote:
>
> GuC PMU busyness gets gt wakeref if awake, but fails to release the
> wakeref if a reset is in progress. Release the wakeref if it was
> acquried successfully.
>
> Signed-off-by: Umesh Nerlige Ramappa
> ---
>
On Wed, 05 Jan 2022 09:21:06 -0800, Matthew Auld wrote:
>
> We need to use the FIXED mapping type on discrete platforms.
Reviewed-by: Ashutosh Dixit
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Cc: Priyanka Dandamudi
> ---
> tests/i915/gem_userptr_blits.c | 5 -
> 1 file
On Thu, 11 Nov 2021 23:10:16 -0800, Vinay Belgaumkar wrote:
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> index 4e1d3cd29164..22c1c12369f2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++
On Sun, 31 Oct 2021 21:39:36 -0700, Belgaumkar, Vinay wrote:
>
> @@ -945,6 +960,17 @@ void intel_rps_boost(struct i915_request *rq)
> if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, >fence.flags)) {
> struct intel_rps *rps = _ONCE(rq->engine)->gt->rps;
>
> + if
On Sun, 31 Oct 2021 21:39:34 -0700, Belgaumkar, Vinay wrote:
>
> Waitboost is a legacy feature implemented in the Host Turbo algorithm. This
> patch set implements it for the SLPC path. A "boost" happens when user
> calls gem_wait ioctl on a submission that has not landed on HW yet.
Afaiu user
On Sun, 31 Oct 2021 21:39:35 -0700, Belgaumkar, Vinay wrote:
>
> Define helpers and struct members required to record boost info.
> Boost frequency is initialized to RP0 at SLPC init. Also define num_waiters
> which can track the pending boost requests.
>
> Boost will be done by scheduling a
On Sun, 31 Oct 2021 21:39:37 -0700, Belgaumkar, Vinay wrote:
>
> +static int set_boost_freq(struct intel_rps *rps, u32 val)
Since this is legacy rps code path maybe change function name to
rps_set_boost_freq?
On Mon, 01 Nov 2021 18:26:05 -0700, Vinay Belgaumkar wrote:
>
> Waitboost is a legacy feature implemented in the Host Turbo algorithm. This
> patch set implements it for the SLPC path. A boost can happen when a request
> is waiting for an unmet dependency. GT frequency gets temporarily bumped to
>
On Mon, 01 Nov 2021 13:28:14 -0700, Dixit, Ashutosh wrote:
>
> On Sun, 31 Oct 2021 21:39:37 -0700, Belgaumkar, Vinay wrote:
> >
> > +static int set_boost_freq(struct intel_rps *rps, u32 val)
>
> Since this is legacy rps code path maybe change function name to
> rps_set_
On Mon, 01 Nov 2021 18:26:08 -0700, Vinay Belgaumkar wrote:
>
> Add a helper to sort through the SLPC/RPS paths of get/set methods.
> Boost frequency will be modified as long as it is within the constraints
> of RP0 and if it is different from the existing one. We will set min
> freq to boost only
On Mon, 01 Nov 2021 18:26:06 -0700, Vinay Belgaumkar wrote:
>
> Define helpers and struct members required to record boost info.
> Boost frequency is initialized to RP0 at SLPC init. Also define num_waiters
> which can track the pending boost requests.
>
> Boost will be done by scheduling a worker
On Mon, 01 Nov 2021 18:26:07 -0700, Vinay Belgaumkar wrote:
>
> Add helper in RPS code for handling SLPC and non-SLPC paths.
> When boost is requested in the SLPC path, we can ask GuC to ramp
> up the frequency req by setting the minimum frequency to boost freq.
> Reset freq back to the min
On Tue, 30 Nov 2021 05:20:05 -0800, Anshuman Gupta wrote:
>
> gt_pm selftest calculates engine ticks cycles and wall time
> cycles by delta of respective engine elapsed TIMESTAMP and ktime
> for period of 1000us.
> It compares the engine ticks cycles with wall time cycles.
>
> Disable local cpu
On Mon, 26 Jul 2021 05:03:08 -0700, Matthew Auld wrote:
>
> We can no longer just call get_caching or set_domain, and the mmap mode
> must be FIXED. This should bring back gem_exec_basic and a few others in
> CI on DG1.
We should probably also similarly update mmap_{read, write} in
On Mon, 26 Jul 2021 05:03:04 -0700, Matthew Auld wrote:
>
> diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> index 4b4f2114..e2514f0c 100644
> --- a/lib/i915/gem_mman.c
> +++ b/lib/i915/gem_mman.c
> @@ -497,6 +497,43 @@ void *gem_mmap_offset__cpu(int fd, uint32_t handle,
> uint64_t
On Tue, 27 Jul 2021 19:01:24 -0700, Dixit, Ashutosh wrote:
>
> On Mon, 26 Jul 2021 05:03:04 -0700, Matthew Auld wrote:
> >
> > diff --git a/lib/i915/gem_mman.c b/lib/i915/gem_mman.c
> > index 4b4f2114..e2514f0c 100644
> > --- a/lib/i915/gem_mman.c
> > +++
On Mon, 14 Mar 2022 08:35:17 -0700, Tvrtko Ursulin wrote:
>
> >> Alternatively, all other uapi uses struct i915_engine_class_instance to
> >> address engines which uses u16:u16.
> >>
> >> How ugly it is to stuff a struct into u32 flags is the question... But you
> >> could at least use u16:u16 for
On Fri, 18 Feb 2022 14:38:53 -0800, Lucas De Marchi wrote:
>
> The move to softpin in igt is ongoing and should land soon.
> Meanwhile, like was done for ADL and RKL, add an exception to allow
> running the igt display tests before that conversion is complete
> so we can unblock CI.
One example
On Tue, 01 Mar 2022 03:03:59 -0800, Matthew Auld wrote:
>
> The shmem mmap and pwrite interfaces conveniently let us probe just a
> few pages, without needing to populate the entire object. On discrete
> and newer platforms the kernel has dropped support for both, leaving us
> with MMAP_OFFSET,
On Mon, 21 Mar 2022 11:17:46 -0700, Lucas De Marchi wrote:
>
> On Mon, Mar 21, 2022 at 10:56:04AM -0700, Ashutosh Dixit wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps_types.h
> > b/drivers/gpu/drm/i915/gt/intel_rps_types.h
> > index 3941d8551f52..5990df35b393 100644
> > ---
On Thu, 24 Mar 2022 07:26:18 -0700, Matthew Auld wrote:
>
> On DG2 the object size might be rounded when allocating lmem. Make sure
> we account for any rounding up.
Reviewed-by: Ashutosh Dixit
On Thu, 24 Mar 2022 07:26:20 -0700, Matthew Auld wrote:
>
> @@ -554,6 +560,7 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
> igt_fixture {
> free(regions);
> close(i915);
> + igt_i915_driver_unload();
I thought we'd reload the
On Thu, 24 Mar 2022 07:26:19 -0700, Matthew Auld wrote:
>
> @@ -353,14 +356,17 @@ static void test_evict(int i915,
> if (flags & TEST_PARALLEL) {
> int fd = gem_reopen_driver(i915);
>
> + ctx = intel_ctx_create_all_physical(fd);
> +
Is anyone looking into fixing this:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c: In function
‘amdgpu_gtt_mgr_recover’:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:200:31: error: ‘struct
ttm_range_mgr_node’ has no member named ‘tbo’
amdgpu_ttm_recover_gart(node->tbo);
On Mon, 28 Mar 2022 03:22:27 -0700, Anshuman Gupta wrote:
>
> +#ifdef CONFIG_PM
> +static int i915_runtime_dump_child_status(struct device *dev, void *data)
> +{
> + struct seq_file *m = data;
> + const char *rpm_status;
> +
> + /* Early return if runtime_pm is disabled */
> + if
On Mon, 21 Mar 2022 11:17:46 -0700, Lucas De Marchi wrote:
>
> On Mon, Mar 21, 2022 at 10:56:04AM -0700, Ashutosh Dixit wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps_types.h
> > b/drivers/gpu/drm/i915/gt/intel_rps_types.h
> > index 3941d8551f52..5990df35b393 100644
> > ---
On Wed, 23 Mar 2022 00:03:23 -0700, Nilawar, Badal wrote:
>
> > +/* "Caps" frequencies should be converted to MHz using intel_gpu_freq() */
> > +void intel_rps_get_freq_caps(struct intel_rps *rps, struct
> > intel_rps_freq_caps *capSis)
>
> Since this function is covering gen6 and above it would
On Tue, 01 Feb 2022 07:19:46 -0800, Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin
>
> Print out end user friendly help text when the running user has
> insufficient privilege for accessing system wide performance counters.
Reviewed-by: Ashutosh Dixit
> Signed-off-by: Tvrtko Ursulin
> Issue:
On Thu, 20 Jan 2022 17:09:28 -0800, john.c.harri...@intel.com wrote:
>
> From: John Harrison
>
> The capture tests require knowing exactly how big the test allocation
> is. Part of the test is to compare the captured size against the
> allocated size to make sure they match. That doesn't work if
On Thu, 06 Jan 2022 08:42:58 -0800, Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin
>
> Commit d7a74b959eea ("tests/i915/perf_pmu: Convert to intel_ctx_t (v3)")
> broke the test when it is run in its entirety.
>
> Correct context id needs to be used with igt_allow_hang to avoid context
> ban
On Wed, 06 Apr 2022 03:09:45 -0700, Anshuman Gupta wrote:
> On 2022-03-24 at 01:24:35 +0530, Ashutosh Dixit wrote:
> > +/* "Caps" frequencies should be converted to MHz using intel_gpu_freq() */
> IMHO, if this exported function deserves a comment, it should Kernel Doc
> comment.
> for an example
1 - 100 of 565 matches
Mail list logo
