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 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 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 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 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: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 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 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, 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 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: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: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 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, 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 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, 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 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 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 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 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 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 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 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 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 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 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 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 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
> +++
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
> -
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 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 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 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, 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 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 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 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 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 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
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 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 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 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 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 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 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 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
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, 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 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 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 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 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 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, 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 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
501 - 568 of 568 matches
Mail list logo
