Use indirect ctx bb to load cmd buffer control value
from context image to avoid corruption.
v2: add to lrc layout (Chris)
v3: end to a cacheline (Chris)
Testcase: igt/i915_selftest/gt_lrc
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 73 +++--
d
On 21/04/2020 10:25, Chris Wilson wrote:
Since we may lose the content of any buffer when we relinquish control
of the system (e.g. suspend/resume), we have to be careful not to rely
on regaining control. A good method to detect when we might be using
garbage is by always injecting that garbage
Chris Wilson writes:
> Let's isolate the impact of cpu frequency selection on determing the GPU
> throughput in response to selection of RPS frequencies.
>
> For real systems, we do have to be concerned with the impact of
> integrating c-states, p-states and rp-states, but for the sake of
> provi
== Series Details ==
Series: drm/i915/gt: Make the slice:unslice ratio request explicit for RPS
URL : https://patchwork.freedesktop.org/series/76269/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17406
Sum
Quoting Chris Wilson (2020-04-21 14:53:54)
> Quoting Chris Wilson (2020-04-21 14:50:51)
> > Quoting Chris Wilson (2020-04-21 14:45:12)
> > > In RPS, we have the option to only specify the unslice [ring] clock
> > > ratio and for the pcu to derive the slice [gpu] clock ratio from its
> > > magic tab
== Series Details ==
Series: series starting with [1/4] drm/i915: Introduce .set_link_train() vfunc
URL : https://patchwork.freedesktop.org/series/76213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8334 -> Patchwork_17391
== Series Details ==
Series: drm/i915/gt: Poison residual state [HWSP] across resume. (rev5)
URL : https://patchwork.freedesktop.org/series/76100/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8342_full -> Patchwork_17399_full
==
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
(rev3)
URL : https://patchwork.freedesktop.org/series/76262/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ebd226e97eaa drm/i915: Make define for lrc state offset
91d36088a541 dr
== Series Details ==
Series: drm/i915/selftests: Disable C-states when measuring RPS frequency
response
URL : https://patchwork.freedesktop.org/series/76272/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17407
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
(rev3)
URL : https://patchwork.freedesktop.org/series/76262/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17408
==
On Mon, Apr 20, 2020 at 02:14:10PM +0300, Stanislav Lisovskiy wrote:
> Future platforms require per-crtc SAGV evaluation
> and serializing global state when those are changed
> from different commits.
>
> v2: - Add has_sagv check to intel_crtc_can_enable_sagv
> so that it sets bit in reject
== Series Details ==
Series: drm/i915/gt: Prefer soft-rc6 over RPS DOWN_TIMEOUT (rev3)
URL : https://patchwork.freedesktop.org/series/76216/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8342_full -> Patchwork_17400_full
Su
Normally when we create a new context, and a new ppGTT to go with it, we
point all the unused pages in the ppGTT to a 'safe' scratch page. Any
inadvertent access outside of the declared user's area will result in a
read/write to scratch instead. However, sometimes it is preferrable to
that to cause
Quoting Chris Wilson (2020-04-21 17:41:30)
> Normally when we create a new context, and a new ppGTT to go with it, we
> point all the unused pages in the ppGTT to a 'safe' scratch page. Any
> inadvertent access outside of the declared user's area will result in a
> read/write to scratch instead. Ho
On Tue, Apr 21, 2020 at 09:51:37AM +0300, Joonas Lahtinen wrote:
> Quoting Sultan Alsawaf (2020-04-20 19:15:14)
> > On Mon, Apr 20, 2020 at 11:21:42AM +0300, Joonas Lahtinen wrote:
> > > So it seems that the patch got pulled into v5.6 and has been backported
> > > to v5.5 but not v5.4.
> >
> > You
On Tue, Apr 21, 2020 at 11:04:13AM +0300, Joonas Lahtinen wrote:
> Quoting Sultan Alsawaf (2020-04-20 18:42:16)
> > On Mon, Apr 20, 2020 at 12:02:39PM +0300, Joonas Lahtinen wrote:
> > > I think the the patch should be dropped for now before the issue is
> > > properly addressed. Either by backport
Having noticed that MI_BB_START is incurring a memory stall (see the
correlation with uncore frequency), we have to unroll the loop in order
to diminish the impact of the MI_BB_START on the instruction throughput.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 32 ++
== Series Details ==
Series: series starting with [01/24] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76255/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8342_full -> Patchwork_17402_full
=
Hi Chris,
On Mon, Apr 20, 2020 at 01:53:55PM +0100, Chris Wilson wrote:
> Since moving the obj->vma.list to a spin_lock, and the vm->bound_list to
> its vm->mutex, along with tracking shrinkable status under its own
> spinlock, we no long require the object to be locked by the caller.
>
> This is
== Series Details ==
Series: RFC drm/i915/gem: Allow creation of contexts with an 'empty' VM
URL : https://patchwork.freedesktop.org/series/76276/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8345 -> Patchwork_17409
Summar
On Mon, Apr 20, 2020 at 7:49 PM Al Viro wrote:
>
> The only source I'd been able to find speaks of >= 60 cycles
> (and possibly much more) for non-pipelined coprocessor instructions;
> the list of such does contain loads and stores to a bunch of registers.
> However, the register in questi
On Mon, 2020-04-20 at 23:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Sort out some of the mess between intel_ddi.c intel_dp.c by
> introducing a .set_signal_levels() vfunc.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/
On Mon, 2020-04-20 at 23:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Relocate a binch of DDI specific code from intel_dp.c to intel_ddi.c
bunch
> by introducing a .set_idle_link_train() vfunc.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers
On Mon, 2020-04-20 at 23:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Split some overly long lines.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletion
== Series Details ==
Series: drm/i915/selftests: Show the full scaling curve on failure (rev2)
URL : https://patchwork.freedesktop.org/series/76260/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8343_full -> Patchwork_17404_full
== Series Details ==
Series: drm/i915/selftests: Unroll the CS frequency loop
URL : https://patchwork.freedesktop.org/series/76277/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8345 -> Patchwork_17410
Summary
---
**
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 983d308cb8f6 ("agp/intel: Serialise after GTT updates").
The bot has tested the following trees: v5.6.5, v5.5.18, v5.4.33, v4.19.116,
v4.14.176, v4.9.219, v4.4.219.
v5.6.5: Build OK
== Series Details ==
Series: series starting with [1/4] drm/i915: Introduce .set_link_train() vfunc
URL : https://patchwork.freedesktop.org/series/76213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8334_full -> Patchwork_17391_full
===
Hi
> > Hm, I see the point of this (and the dev_field below, although I'd go
> > with dev_member there for some consistency with other macros using
> > offset_of or container_of), but I'm not sure about the dev_ prefix.
> > Drivers use that sometimes for the struct device *, and usage for
> > stru
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
(rev3)
URL : https://patchwork.freedesktop.org/series/76262/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8343_full -> Patchwork_17408_full
On 04/15, Maxime Ripard wrote:
> Hi!
>
> On Mon, Oct 21, 2019 at 10:00:39PM -0300, Brian Starkey wrote:
> > Add a test which makes commits using the writeback connector, and
> > checks the output buffer hash to make sure it is/isn't written as
> > appropriate.
> >
> > V6: Simon Ser
> > - Add igt
Since batch buffers dominant execution time, most preemption requests
should naturally occur during execution of a batch buffer. We wish to
verify that should a preemption occur within a batch buffer, when we
come to restart that batch buffer, it occurs at the interrupted
instruction and most impor
== Series Details ==
Series: drm/i915/selftests: Try to detect rollback during batchbuffer preemption
URL : https://patchwork.freedesktop.org/series/76279/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8346 -> Patchwork_17411
===
On Tue, Apr 21, 2020 at 09:38:09AM -0700, Sultan Alsawaf wrote:
> Why hasn't this bug got any attention:
> https://gitlab.freedesktop.org/drm/intel/issues/1412
>
> That seems like a showstopper.
Indeed, pretty shocking. It's worth mentioning that the reporter of said
bug, after significant time h
On Thu, Apr 02, 2020 at 04:55:06PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 01, 2020 at 04:53:23PM -0700, Manasi Navare wrote:
> > On Wed, Feb 12, 2020 at 06:17:34PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Most of the pfit functions are of the form:
> > >
> > > func()
Add tracek to the RPS events (interrupts, worker, enabling, threshold
selection, frequency setting), so that if we have to debug reticent HW
we have some traces to start from.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_rps.c | 48 ++---
1 file changed,
The RPS DOWN_TIMEOUT interrupt is signaled after a period of rc6, and
upon receipt of that interrupt we reprogram the GPU clocks down to the
next idle notch [to help convserve power during rc6]. However, on
execlists, we benefit from soft-rc6 immediately parking the GPU and
setting idle frequencies
For many configuration details within RC6 and RPS we are programming
intervals for the internal clocks. From gen11, these clocks are
configuration via the RPM_CONFIG and so for convenience, we would like
to convert to/from more natural units (ns).
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: M
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Prefer soft-rc6 over RPS
DOWN_TIMEOUT
URL : https://patchwork.freedesktop.org/series/76283/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3703f8b4e6fc drm/i915/gt: Prefer soft-rc6 over RPS DOWN_TIMEOUT
288657
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Prefer soft-rc6 over RPS
DOWN_TIMEOUT
URL : https://patchwork.freedesktop.org/series/76283/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8346 -> Patchwork_17412
=
== Series Details ==
Series: drm/i915/selftests: Unroll the CS frequency loop
URL : https://patchwork.freedesktop.org/series/76277/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8345_full -> Patchwork_17410_full
Summary
---
== Series Details ==
Series: drm/i915/selftests: Try to detect rollback during batchbuffer preemption
URL : https://patchwork.freedesktop.org/series/76279/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8346_full -> Patchwork_17411_full
=
Hi,
Here's current gvt-next. This removes left non-upstream xen support bits
which will be kept out of tree instead. And several guest context shadow
optimizations from Yan.
Thanks
--
The following changes since commit a61ac1e75105a077ec1efd6923ae3c619f862304:
drm/i915/gvt: Wean gvt off usin
On Tue, Apr 21, 2020 at 09:21:42PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> There is no reason for a user to select this or not directly - it should
> be selected by drivers that are going to use the feature, similar to how
> CONFIG_HMM_MIRROR works.
>
> Currently all drivers pr
On Tue, Apr 21, 2020 at 09:21:43PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> hmm_vma_walk->last is supposed to be updated after every write to the
> pfns, so that it can be returned by hmm_range_fault(). However, this is
> not done consistently. Fortunately nothing checks the retu
On Tue, Apr 21, 2020 at 09:21:45PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
> because of a special page vs any other error case.
Looks good,
Reviewed-by: Christoph Hellwig
___
On Tue, Apr 21, 2020 at 09:21:46PM -0300, Jason Gunthorpe wrote:
> +void nouveau_hmm_convert_pfn(struct nouveau_drm *drm, struct hmm_range
> *range,
> + u64 *ioctl_addr)
> {
> unsigned long i, npages;
>
> + /*
> + * The ioctl_addr prepared here is pass
101 - 147 of 147 matches
Mail list logo
