On Mon, Mar 26, 2018 at 09:08:33PM +0100, Chris Wilson wrote:
> Quoting Patchwork (2018-03-26 17:53:44)
> > Test gem_userptr_blits:
> > Subgroup coherency-unsync:
> > pass -> INCOMPLETE (shard-hsw)
>
> Forgot that obj->userptr.mn may not exist.
>
> > Subgroup
Quoting Daniel Vetter (2018-03-27 07:48:00)
> On Mon, Mar 26, 2018 at 11:38:55PM +0100, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-03-26 21:08:33)
> > > Quoting Patchwork (2018-03-26 17:53:44)
> > > > Test gem_userptr_blits:
> > > > Subgroup coherency-unsync:
> > > >
Quoting Daniel Vetter (2018-03-27 08:01:17)
> On Mon, Mar 26, 2018 at 09:08:33PM +0100, Chris Wilson wrote:
> > Quoting Patchwork (2018-03-26 17:53:44)
> > > Test gem_userptr_blits:
> > > Subgroup coherency-unsync:
> > > pass -> INCOMPLETE (shard-hsw)
> >
> > Forgot t
On Mon, Mar 26, 2018 at 02:28:48PM -0700, Daniele Ceraolo Spurio wrote:
> + igt-dev
>
> On 21/03/18 07:23, Katarzyna Dec wrote:
> > During debugging gpgpu_fill test on various platforms, I found out few
> > things that can affect newer gens:
>
> this is slightly confusing, as you start with sayin
On Thu, Mar 22, 2018 at 05:22:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of assigning the plane->fb pointer and clearing the fb pointer
> to hand over the reference, let's just do it by grabbing another
> referece for plane->fb and let fb keep its original one.
>
> Signed
On Thu, Mar 22, 2018 at 05:23:05PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Stop playing around with plane->crtc/fb/old_fb with atomic
> drivers. Make life a lot simpler when we don't have to do the
> magic old_fb vs. fb dance around plane updates. That way we
> can't risk plane->fb
On Thu, Mar 22, 2018 at 05:22:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Stop looking at plane->fb on atomic drivers. Use plane->state->fb
> instead.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/gp
On Thu, Mar 22, 2018 at 05:23:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We want to get rid of plane->fb on atomic drivers. Stop looking at it.
>
> Cc: Boris Brezillon
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 12 +---
> 1
Chris Wilson writes:
> When cancelling the requests and clearing out the ports following a
> successful preemption completion, also clear the active flag. I had
> assumed that all preemptions would be followed by an immediate dequeue
> (preserving the active user flag), but under rare circumstanc
On Thu, Mar 22, 2018 at 05:22:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I really just wanted to fix i915 to re-enable its planes afer load
> detection (a two line patch). This is what I actually ended up with
> after I ran into a framebuffer refcount leak with said two line patch
On 26/03/2018 12:50, Chris Wilson wrote:
Use a liberal timeout of 20ms to ensure that the rendering for an
interactive pageflip is started in a timely fashion, and that
user interaction is not blocked by GPU, or CPU, hogs. This is at the cost
of resetting whoever was blocking the preemption, lik
Chris Wilson writes:
> For the off-chance we have an interrupt posted and haven't processed the
> CSB.
>
> v2: Include tasklet enable/disable state for good measure.
Reviewed-by: Mika Kuoppala
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 7 +--
> 1 fil
The test is whether with all but one engine busy we record the correct
load on each engine. If we only have one engine, this test degenerates
into all-idle/all-busy, so we can skip to avoid crashing on the
assumption that we have a busy spinner.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Quoting Tvrtko Ursulin (2018-03-27 09:35:17)
>
> On 26/03/2018 12:50, Chris Wilson wrote:
> > Use a liberal timeout of 20ms to ensure that the rendering for an
> > interactive pageflip is started in a timely fashion, and that
> > user interaction is not blocked by GPU, or CPU, hogs. This is at the
Quoting Mika Kuoppala (2018-03-27 09:18:55)
> Chris Wilson writes:
>
> > When cancelling the requests and clearing out the ports following a
> > successful preemption completion, also clear the active flag. I had
> > assumed that all preemptions would be followed by an immediate dequeue
> > (pres
Hi, Joonas
Here's this week's gvt-next-fixes queued for 4.17. One notable change
is to revert previous workaround for gvt context preemption, now it
has full support for preemption now. Others are normal fixes and
optimizations.
Thanks
--
The following changes since commit d8303075699292008ae5b2
On 26/03/2018 12:50, Chris Wilson wrote:
Install a timer when trying to preempt on behalf of an important
context such that if the active context does not honour the preemption
request within the desired timeout, then we reset the GPU to allow the
important context to run.
I suggest renaming p
On 27/03/2018 09:37, Chris Wilson wrote:
The test is whether with all but one engine busy we record the correct
load on each engine. If we only have one engine, this test degenerates
into all-idle/all-busy, so we can skip to avoid crashing on the
assumption that we have a busy spinner.
Signed-o
Quoting Tvrtko Ursulin (2018-03-27 09:54:35)
>
> On 27/03/2018 09:37, Chris Wilson wrote:
> > The test is whether with all but one engine busy we record the correct
> > load on each engine. If we only have one engine, this test degenerates
> > into all-idle/all-busy, so we can skip to avoid crashi
On 27/03/2018 09:39, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-27 09:35:17)
On 26/03/2018 12:50, Chris Wilson wrote:
Use a liberal timeout of 20ms to ensure that the rendering for an
interactive pageflip is started in a timely fashion, and that
user interaction is not blocked by GPU
Quoting Tvrtko Ursulin (2018-03-27 09:51:20)
>
> On 26/03/2018 12:50, Chris Wilson wrote:
> > Install a timer when trying to preempt on behalf of an important
> > context such that if the active context does not honour the preemption
> > request within the desired timeout, then we reset the GPU to
Chris Wilson writes:
> When cancelling the requests and clearing out the ports following a
> successful preemption completion, also clear the active flag. I had
> assumed that all preemptions would be followed by an immediate dequeue
> (preserving the active user flag), but under rare circumstanc
Quoting Tvrtko Ursulin (2018-03-27 09:51:20)
>
> On 26/03/2018 12:50, Chris Wilson wrote:
> > +static enum hrtimer_restart preempt_timeout(struct hrtimer *hrtimer)
> > +{
> > + struct intel_engine_execlists *execlists =
> > + container_of(hrtimer, typeof(*execlists), preempt_timer)
On 03/02/2018 04:09 PM, kevin.rogo...@intel.com wrote:
> From: Kevin Rogovin
>
> This patch provides additional overview documentation to the
> i915 kernel driver GEM. In addition, it presents already written
> documentation to i915.rst as well.
>
> Signed-off-by: Kevin Rogovin
Makes sense.
On Tue, Mar 27, 2018 at 09:57:41AM +0200, Daniel Vetter wrote:
> On Thu, Mar 22, 2018 at 05:23:05PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Stop playing around with plane->crtc/fb/old_fb with atomic
> > drivers. Make life a lot simpler when we don't have to do the
> > magic ol
Across suspend, we may see a very large drift in timestamps if the sched
clock is unstable, prompting the global trace's ringbuffer code to warn
and suggest switching to the global clock. Preempt this request by
detecting when the sched clock is unstable (determined during
late_initcall) and automa
Quoting Chris Wilson (2018-03-27 10:55:35)
> Across suspend, we may see a very large drift in timestamps if the sched
> clock is unstable, prompting the global trace's ringbuffer code to warn
> and suggest switching to the global clock. Preempt this request by
> detecting when the sched clock is un
Quoting Chris Wilson (2018-03-27 11:00:32)
> Quoting Chris Wilson (2018-03-26 12:50:35)
> > When cancelling the requests and clearing out the ports following a
> > successful preemption completion, also clear the active flag. I had
> > assumed that all preemptions would be followed by an immediate
On Tue, Mar 27, 2018 at 08:19:33AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2018-03-27 07:48:00)
> > On Mon, Mar 26, 2018 at 11:38:55PM +0100, Chris Wilson wrote:
> > > Quoting Chris Wilson (2018-03-26 21:08:33)
> > > > Quoting Patchwork (2018-03-26 17:53:44)
> > > > > Test gem_userptr_b
Quoting Chris Wilson (2018-03-26 12:50:35)
> When cancelling the requests and clearing out the ports following a
> successful preemption completion, also clear the active flag. I had
> assumed that all preemptions would be followed by an immediate dequeue
> (preserving the active user flag), but un
On 3/27/2018 1:18 AM, Michal Wajdeczko wrote:
As we are going to extend our use of MMIO based communication,
try to explain its mechanics and update corresponding definitions.
v2: fix checkpatch MACRO_ARG_REUSE
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Sagar Arun Kamble
On Sat, Mar 24, 2018 at 12:26:32PM -0500, David Lechner wrote:
> On 03/22/2018 03:27 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We'll need access to the plane state during .atomic_enable().
> >
>
> Some more details in the commit message would be useful. It is
> not clear to me wh
Quoting Daniel Vetter (2018-03-27 11:01:09)
> On Tue, Mar 27, 2018 at 08:19:33AM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2018-03-27 07:48:00)
> > > On Mon, Mar 26, 2018 at 11:38:55PM +0100, Chris Wilson wrote:
> > > > Quoting Chris Wilson (2018-03-26 21:08:33)
> > > > > Quoting Patchw
On 26/03/18 20:33, Matthew Auld wrote:
On 26 March 2018 at 20:21, Matthew Auld wrote:
On 26 March 2018 at 10:08, Lionel Landwerlin
wrote:
We want to use some of the properties of the perf stream to program
the hardware in a later commit.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/dr
On Tue, 20 Mar 2018, Sagar Arun Kamble wrote:
> On 3/20/2018 6:30 PM, Michal Wajdeczko wrote:
>> On Tue, 20 Mar 2018 08:24:14 +0100, Sagar Arun Kamble
>> wrote:
>>
>>>
>>>
>>> On 3/19/2018 8:58 PM, Michal Wajdeczko wrote:
There is no need to mix parameter types in public CT functions
a
== Series Details ==
Series: trace: Default to using trace_global_clock is sched_clock is unstable
URL : https://patchwork.freedesktop.org/series/40725/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e5c9ab3af1d9 trace: Default to using trace_global_clock is sched_clock is
unst
On Mon, Mar 26, 2018 at 06:16:22PM -0700, Dhinakaran Pandiyan wrote:
> Interrupts other than the one for AUX errors are required only for debug,
> so unmask them via debugfs when the user requests debug.
>
> User can make such a request with
> echo 1 > /dri/0/i915_edp_psr_debug
>
> v2: Unroll loo
From: Kevin Rogovin
Signed-off-by: Kevin Rogovin
---
drivers/gpu/drm/i915/intel_ringbuffer.h | 38 +
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 62d3a22..2f8908e 100644
--
From: Kevin Rogovin
Note: I want to make a one or two follow-up series that provide
narration and potentially additional documentation for GUC submission
and the breadcrumbs.
v3:
More documentation: emphasize that handling of batchbuffer
requests creates a request struct that is added to t
From: Kevin Rogovin
Signed-off-by: Kevin Rogovin
---
Documentation/gpu/i915.rst | 129 +---
drivers/gpu/drm/i915/i915_vma.h | 10 +++-
2 files changed, 113 insertions(+), 26 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.
From: Kevin Rogovin
Signed-off-by: Kevin Rogovin
---
drivers/gpu/drm/i915/intel_ringbuffer.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 1f50727..62d3a22 100644
--
From: Kevin Rogovin
Signed-off-by: Kevin Rogovin
---
drivers/gpu/drm/i915/i915_request.h | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 7d6eb82..093b9d7 100644
--- a/drivers/gpu/d
From: Kevin Rogovin
Signed-off-by: Kevin Rogovin
---
Documentation/gpu/i915.rst | 58 +++---
1 file changed, 49 insertions(+), 9 deletions(-)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index ed8e08d..b23d5c9 100644
--- a/Documen
Quoting Dhinakaran Pandiyan (2018-03-27 02:16:22)
> Interrupts other than the one for AUX errors are required only for debug,
> so unmask them via debugfs when the user requests debug.
>
> User can make such a request with
> echo 1 > /dri/0/i915_edp_psr_debug
>
> v2: Unroll loops (Ville)
> Av
Quoting kevin.rogo...@intel.com (2018-03-27 11:26:14)
> From: Kevin Rogovin
>
> Note: I want to make a one or two follow-up series that provide
> narration and potentially additional documentation for GUC submission
> and the breadcrumbs.
>
> v3:
>More documentation: emphasize that handling
Across suspend, we may see a very large drift in timestamps if the sched
clock is unstable, prompting the global trace's ringbuffer code to warn
and suggest switching to the global clock. Preempt this request by
detecting when the sched clock is unstable (determined during
late_initcall) and automa
Hi,
>>Call out GEM_EXECBUFFER as deprecated.
> Oh not it isn't. _WR has a singular purpose that isn't even the recommend
> method any more.
I had understood that DRM_I915_GEM_EXECBUFFER was considered deprecated.
I will fix this mistake on next spin.
I had thought that DRM_i915_GEM_EXECBUF
== Series Details ==
Series: trace: Default to using trace_global_clock is sched_clock is unstable
URL : https://patchwork.freedesktop.org/series/40725/
State : success
== Summary ==
Series 40725v1 trace: Default to using trace_global_clock is sched_clock is
unstable
https://patchwork.freedes
On 02/03/2018 14:09, kevin.rogo...@intel.com wrote:
From: Kevin Rogovin
This patch provides additional overview documentation to the
i915 kernel driver GEM. In addition, it presents already written
documentation to i915.rst as well.
Signed-off-by: Kevin Rogovin
---
Documentation/gpu/i915.r
== Series Details ==
Series: Documentation patch for batchbuffer submission (rev3)
URL : https://patchwork.freedesktop.org/series/38433/
State : success
== Summary ==
Series 38433v3 Documentation patch for batchbuffer submission
https://patchwork.freedesktop.org/api/1.0/series/38433/revisions/
When asserting the switch to the kernel context is complete, we know
that the requests should also have been retired. We can assert that this
is so in order to give us some more insight into the state of affairs
should we ever see a bug along this path, such as:
<4>[ 206.836931] WARN_ON(dev_priv-
== Series Details ==
Series: trace: Default to using trace_global_clock if sched_clock is unstable
URL : https://patchwork.freedesktop.org/series/40728/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c393b9561028 trace: Default to using trace_global_clock if sched_clock is
unst
Quoting Mika Kuoppala (2018-03-27 10:22:11)
> Chris Wilson writes:
>
> > When cancelling the requests and clearing out the ports following a
> > successful preemption completion, also clear the active flag. I had
> > assumed that all preemptions would be followed by an immediate dequeue
> > (pres
== Series Details ==
Series: trace: Default to using trace_global_clock if sched_clock is unstable
URL : https://patchwork.freedesktop.org/series/40728/
State : success
== Summary ==
Series 40728v1 trace: Default to using trace_global_clock if sched_clock is
unstable
https://patchwork.freedes
This reverts commit 52e7aa851c22613f9f57e01a6bdb1970e6cb3a41,
re-enabling commit 3b5b899ca67db07a4c4825911072221f99e157e2.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105069
Cc: Abhijeet Kumar
---
sound/pci/hda/hda_codec.c | 28 +---
sound/pci/hda/hda_local.h
Chris Wilson writes:
> If the request is still waiting on external fences, it has not yet been
> submitted to the HW queue and so we can forgo kicking the submission
> tasklet when re-evaluating its priority.
>
> This should have no impact other than reducing the number of tasklet
> wakeups under
On Tue, 27 Mar 2018 12:05:21 +0200, Sagar Arun Kamble
wrote:
On 3/27/2018 1:18 AM, Michal Wajdeczko wrote:
As we are going to extend our use of MMIO based communication,
try to explain its mechanics and update corresponding definitions.
v2: fix checkpatch MACRO_ARG_REUSE
Signed-off-by: M
Chris Wilson writes:
> If the request is still waiting on external fences, it has not yet been
> submitted to the HW queue and so we can forgo kicking the submission
> tasklet when re-evaluating its priority.
>
> This should have no impact other than reducing the number of tasklet
> wakeups under
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
v2: Restore checking of use_csb_mmio on every loop, don't forget old
vgpu.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
-
Quoting Mika Kuoppala (2018-03-27 12:34:31)
> Chris Wilson writes:
>
> > If the request is still waiting on external fences, it has not yet been
> > submitted to the HW queue and so we can forgo kicking the submission
> > tasklet when re-evaluating its priority.
> >
> > This should have no impact
== Series Details ==
Series: drm/i915: Check all requests have been retired on switching to kernel
context
URL : https://patchwork.freedesktop.org/series/40730/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
84242a8ea607 drm/i915: Check all requests have been retired on switchi
Hi,
Thankyou for the very thorough read and comments, this is exactly what is
needed to give it polish and become a good intro to GEM in i915; I just wished
I had waited on posting a v3 just a few more hours and I would have been able
to use all this for v3. I will use all of your comments in
== Series Details ==
Series: drm/i915: Check all requests have been retired on switching to kernel
context
URL : https://patchwork.freedesktop.org/series/40730/
State : success
== Summary ==
Series 40730v1 drm/i915: Check all requests have been retired on switching to
kernel context
https://
== Series Details ==
Series: Restore "ALSA: hda: Make use of core codec functions to sync power
state"
URL : https://patchwork.freedesktop.org/series/40731/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d925f55eae55 Restore "ALSA: hda: Make use of core codec functions to sync
Instead of returning small data in response status dword,
GuC may append longer data as response message payload.
If caller provides response buffer, we will copy received
data and use number of received data dwords as new success
return value. We will WARN if response from GuC does not
match calle
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-03-27 12:34:31)
>> Chris Wilson writes:
>>
>> > If the request is still waiting on external fences, it has not yet been
>> > submitted to the HW queue and so we can forgo kicking the submission
>> > tasklet when re-evaluating its priority.
>> >
== Series Details ==
Series: Restore "ALSA: hda: Make use of core codec functions to sync power
state"
URL : https://patchwork.freedesktop.org/series/40731/
State : failure
== Summary ==
Series 40731v1 Restore "ALSA: hda: Make use of core codec functions to sync
power state"
https://patchwor
== Series Details ==
Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the
submission too early for rescheduling (rev2)
URL : https://patchwork.freedesktop.org/series/40665/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
faa8da6b86be drm/i915/execlists: Avo
== Series Details ==
Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the
submission too early for rescheduling (rev2)
URL : https://patchwork.freedesktop.org/series/40665/
State : success
== Summary ==
Series 40665v2 series starting with [01/11] drm/i915/execlists: Avoi
Hi Matt,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16-rc7 next-20180326]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/com
Quoting Mika Kuoppala (2018-03-27 13:18:06)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-03-27 12:34:31)
> >> Chris Wilson writes:
> >>
> >> > If the request is still waiting on external fences, it has not yet been
> >> > submitted to the HW queue and so we can forgo kicking the sub
== Series Details ==
Series: drm/i915/guc: Support for Guc responses and requests (rev4)
URL : https://patchwork.freedesktop.org/series/28393/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/guc: Add documentation for MMIO based communication
Okay!
Commit: drm/i915/
Quoting Zhenyu Wang (2018-03-27 11:39:42)
>
> Hi, Joonas
>
> Here's this week's gvt-next-fixes queued for 4.17. One notable change
> is to revert previous workaround for gvt context preemption, now it
> has full support for preemption now.
I've pulled the patches, but this revert sounds fishy.
== Series Details ==
Series: drm/i915/guc: Support for Guc responses and requests (rev4)
URL : https://patchwork.freedesktop.org/series/28393/
State : success
== Summary ==
Series 28393v4 drm/i915/guc: Support for Guc responses and requests
https://patchwork.freedesktop.org/api/1.0/series/2839
== Series Details ==
Series: trace: Default to using trace_global_clock is sched_clock is unstable
URL : https://patchwork.freedesktop.org/series/40725/
State : success
== Summary ==
Known issues:
Test gem_softpin:
Subgroup noreloc-s3:
pass -> INCOMPLETE (sh
== Series Details ==
Series: Documentation patch for batchbuffer submission (rev3)
URL : https://patchwork.freedesktop.org/series/38433/
State : failure
== Summary ==
Possible new issues:
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
== Series Details ==
Series: trace: Default to using trace_global_clock if sched_clock is unstable
URL : https://patchwork.freedesktop.org/series/40728/
State : success
== Summary ==
Known issues:
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
pass
Yunwei Zhang writes:
> WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO
> read into Slice/Subslice specific registers, MCR packet control
> register(0xFDC) needs to be programmed to point to any enabled
> slice/subslice pair. Otherwise, incorrect value will be returned.
strtod() is locale-dependent. The decimal conversion depends on the radix
character ('.' for some of us like myself) varies by locale. As the
kernel reports its values using the "C" locale, we need to switch to
that when parsing; and switch back before reporting to the user.
Bugzilla: https://bugs
Quoting Tvrtko Ursulin (2018-03-26 17:57:38)
>
> On 26/03/2018 17:12, Yunwei Zhang wrote:
> > ---
> > drivers/gpu/drm/i915/i915_drv.h| 1 +
> > drivers/gpu/drm/i915/intel_engine_cs.c | 39
> > --
> > 2 files changed, 38 insertions(+), 2 deletions(-)
>
Quoting Joonas Lahtinen (2018-03-27 16:42:28)
> Quoting Zhenyu Wang (2018-03-27 11:39:42)
> >
> > Hi, Joonas
> >
> > Here's this week's gvt-next-fixes queued for 4.17. One notable change
> > is to revert previous workaround for gvt context preemption, now it
> > has full support for preemption no
On 27/03/2018 15:28, Chris Wilson wrote:
strtod() is locale-dependent. The decimal conversion depends on the radix
character ('.' for some of us like myself) varies by locale. As the
kernel reports its values using the "C" locale, we need to switch to
that when parsing; and switch back before re
Hi Dave,
Two human-reported bugs to close for display and a more rare fix
that could result in GPU hang.
There was some unclarity about the GVT pull, so I'm not including
it here.
Happy Easter holidays!
Regards, Joonas
drm-intel-next-fixes-2018-03-27:
- Display fixes for booting with MST hub l
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.
Preemption in previous gens required a special batch buffer to be executed,
so the Command Streamer never preempted to idle dir
== Series Details ==
Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the
submission too early for rescheduling (rev2)
URL : https://patchwork.freedesktop.org/series/40665/
State : failure
== Summary ==
Possible new issues:
Test gem_ctx_param:
Subgroup inva
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists.
URL : https://patchwork.freedesktop.org/series/40747/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
96268839cd00 drm/i915/gen11: Preempt-to-idle support in execlists.
-:97: CHECK:COMPARISON_TO_NU
[resend for typo in cc]
On 27/03/2018 14:48, Chris Wilson wrote:
If we inject a reset into the target context, there is a risk that the
register state is never saved back to memory. The exact interaction
between reset, the context image and the precise timing of our execution
are not well defin
[resend for typo in cc]
On 27/03/2018 14:59, Chris Wilson wrote:
Quoting Chris Wilson (2018-03-27 14:52:20)
Quoting Chris Wilson (2018-03-27 14:48:43)
If we inject a reset into the target context, there is a risk that the
register state is never saved back to memory. The exact interaction
bet
On Tue, Mar 27, 2018 at 12:44:02PM +0100, Chris Wilson wrote:
> Catch up with the inflight CSB events, after disabling the tasklet
> before deciding which request was truly guilty of hanging the GPU.
>
> v2: Restore checking of use_csb_mmio on every loop, don't forget old
> vgpu.
>
> Signed-off-b
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists.
URL : https://patchwork.freedesktop.org/series/40747/
State : success
== Summary ==
Series 40747v1 drm/i915/gen11: Preempt-to-idle support in execlists.
https://patchwork.freedesktop.org/api/1.0/series/40747/rev
On Tue, Mar 27, 2018 at 09:51:20AM +0100, Tvrtko Ursulin wrote:
>
> On 26/03/2018 12:50, Chris Wilson wrote:
> >Install a timer when trying to preempt on behalf of an important
> >context such that if the active context does not honour the preemption
> >request within the desired timeout, then we
Quoting Tvrtko Ursulin (2018-03-27 16:41:14)
>
> [resend for typo in cc]
The small advantage in redundancy, I guess.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Mar 26, 2018 at 12:50:41PM +0100, Chris Wilson wrote:
> Install a timer when trying to preempt on behalf of an important
> context such that if the active context does not honour the preemption
> request within the desired timeout, then we reset the GPU to allow the
> important context to r
On 3/26/2018 9:57 AM, Tvrtko Ursulin wrote:
On 26/03/2018 17:12, Yunwei Zhang wrote:
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any
MMIO
read into Slice/Subslice specific registers, MCR packet control
register(0xFDC) needs to be programmed to point to any enabled
slice
On 3/16/2018 1:28 PM, Daniele Ceraolo Spurio wrote:
On 16/03/18 05:14, Mika Kuoppala wrote:
From: Michel Thierry
The bits used to reset the different engines/domains have changed in
GEN11, this patch maps the reset engine mask bits with the new bits
in the reset control register.
v2: Use sh
On 03/27/2018 05:07 AM, Ville Syrjälä wrote:
On Sat, Mar 24, 2018 at 12:26:32PM -0500, David Lechner wrote:
On 03/22/2018 03:27 PM, Ville Syrjala wrote:
From: Ville Syrjälä
We'll need access to the plane state during .atomic_enable().
Some more details in the commit message would be useful
From: Tvrtko Ursulin
Contexts executing when reset triggers are potentialy corrupt so trying to
use them from a subsequent test (like the default context) can hang the
GPU or even the driver.
Workaround that by always creating a dedicated context which will be
running when GPU reset happens.
Si
On Mon, 26 Mar 2018 12:36:05 +0200, Sagar Arun Kamble
wrote:
On 3/23/2018 8:44 PM, Michal Wajdeczko wrote:
We should not leave GuC submission enabled after sanitize,
as we are going to reset all GuC/HuC hardware.
Signed-off-by: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Ei
On Mon, 26 Mar 2018 13:23:21 +0200, Sagar Arun Kamble
wrote:
On 3/23/2018 8:44 PM, Michal Wajdeczko wrote:
Today uc_fini_hw is subset of uc_sanitize, but remaining
code in sanitize function is also desired for uc_fini_hw.
Instead of duplicating the code, just call uc_sanitize,
but leave as
== Series Details ==
Series: drm/i915/guc: Support for Guc responses and requests (rev4)
URL : https://patchwork.freedesktop.org/series/28393/
State : failure
== Summary ==
Possible new issues:
Test gem_eio:
Subgroup execbuf:
pass -> INCOMPLETE (shard-apl)
1 - 100 of 175 matches
Mail list logo
