[Intel-gfx] ✗ Ro.CI.BAT: failure for Execlist based Engine reset patches (rev4)

== Series Details == Series: Execlist based Engine reset patches (rev4) URL : https://patchwork.freedesktop.org/series/10283/ State : failure == Summary == Applying: drm/i915: Update i915.reset to handle engine resets Applying: drm/i915: Separate out reset flags from the reset counter

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Fix up some stray to_i915(dev) after a recent merge

== Series Details == Series: drm/i915: Fix up some stray to_i915(dev) after a recent merge URL : https://patchwork.freedesktop.org/series/10327/ State : failure == Summary == Series 10327v1 drm/i915: Fix up some stray to_i915(dev) after a recent merge

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm/i915: Clear per-engine fault register as early as possible

== Series Details == Series: series starting with [1/2] drm/i915: Clear per-engine fault register as early as possible URL : https://patchwork.freedesktop.org/series/10326/ State : failure == Summary == Series 10326v1 Series without cover letter

[Intel-gfx] [PATCH 2/3] lrc

--- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_gem.c | 6 +- drivers/gpu/drm/i915/i915_gem_request.h | 24 +- drivers/gpu/drm/i915/intel_lrc.c| 416 +++- drivers/gpu/drm/i915/intel_lrc.h| 2 -

[Intel-gfx] [PATCH 1/3] drm/i915: Record the position of the start of the request

Not only does it make for good documentation and debugging aide, but it is also vital for when we want to unwind requests - such as when throwing away an incomplete request. v2: Rebase Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 +

[Intel-gfx] [PATCH 3/3] reset-request-recovery

--- drivers/gpu/drm/i915/i915_drv.c | 4 +- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_gem.c | 66 + drivers/gpu/drm/i915/i915_gem_context.c | 16 drivers/gpu/drm/i915/intel_lrc.c| 34

[Intel-gfx] Resubmitting requests following the hang

To clarify what I mean about knowing what values we need to write into the ring following the reset, please consider these poc patches which implement request recovery following the global reset. -Chris ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 4/5] drm/i915/guc: add engine mask to GuC client & pass to GuC

Hi, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20160727] [cannot apply to v4.7] [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/commits/Dave-Gordon/drm-i915

[Intel-gfx] [PATCH] drm/i915: Fix up some stray to_i915(dev) after a recent merge

The merge conflict resolution caused some dev->dev_private to return from the dead. Kill them with to_i915(). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_sysfs.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 2 files changed, 3 insertions(+), 3

[Intel-gfx] [PATCH 2/2] drm/i915: Fix use of engine->index for register offset

Since commit de1add360522 ("drm/i915: Decouple execbuf uAPI from internal implementation") the index of the engine (its engine->id) in the internal list no longer matches the hardware id. However, in a couple of locations we missed fixing up the difference. In this case, RING_FAULT_REG() refers to

Re: [Intel-gfx] [PATCH 12/18] drm/i915: Unify request submission

On Wed, Jul 27, 2016 at 07:09:15PM +0100, Chris Wilson wrote: > On Wed, Jul 27, 2016 at 06:51:35PM +0100, Dave Gordon wrote: > > >>@@ -1006,6 +1005,10 @@ int i915_guc_submission_enable(struct > > >>drm_i915_private *dev_priv) > > >> host2guc_sample_forcewake(guc, client); > > >>

[Intel-gfx] [PATCH 1/2] drm/i915: Clear per-engine fault register as early as possible

From gen6, the hardware tracks address lookup failures and so that we do not trigger false positives from errors before we are initialised we clear those upon startup (intel_uncore_early_sanitize()). However, this is actually before we have the engines defined and this turns out to be a nop. The

Re: [Intel-gfx] [PATCH 12/18] drm/i915: Unify request submission

On Wed, Jul 27, 2016 at 06:51:35PM +0100, Dave Gordon wrote: > >>@@ -1006,6 +1005,10 @@ int i915_guc_submission_enable(struct > >>drm_i915_private *dev_priv) > >>host2guc_sample_forcewake(guc, client); > >>guc_init_doorbell_hw(guc); > >> > >>+ /* Take over from manual control of ELSP

Re: [Intel-gfx] [PATCHv7 5/5] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

On Wed, Jul 27, 2016 at 11:20:18AM +, R, Durgadoss wrote: > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > Sent: Wednesday, July 27, 2016 3:28 PM > > To: R, Durgadoss > > Cc: intel-gfx@lists.freedesktop.org; Conselvan De

Re: [Intel-gfx] [PATCH 12/18] drm/i915: Unify request submission

On 22/07/16 09:03, Joonas Lahtinen wrote: On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: Move request submission from emit_request into its own common vfunc from i915_add_request(). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c|

Re: [Intel-gfx] [PATCH 40/55] drm/i915: Refactor blocking waits

On Wed, Jul 27, 2016 at 01:42:13PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-27 at 08:07 +0100, Chris Wilson wrote: > > >  > > > > +   active = obj->last_read; > > > > +   active_mask = obj->active; > > > > } else { > > > > -   for (i = 0; i < I915_NUM_ENGINES;

[Intel-gfx] [PACTH i-g-t v5 13/13] lib/Makefile: Replace automake specific names of listings in Makefile.sources

From: Robert Foss Replace the automake specific variable names for listings in Makefile.sources with something not automake specific. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov --- lib/Android.mk

[Intel-gfx] [PACTH i-g-t v5 12/13] lib/tests/Makefile: Replace automake specific names of listings in Makefile.sources

From: Robert Foss Replace the automake specific names of listings with something that isn't automake specific. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov --- lib/tests/Android.mk | 2 +-

[Intel-gfx] [PACTH i-g-t v5 11/13] tools/Makefile: Replace automake specific name of listings in Makfile.sources

From: Robert Foss Replace the automake specific names of listings in Makefile.sources with something not automake specific. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov --- tools/Android.mk | 1 +

[Intel-gfx] [PACTH i-g-t v5 07/13] demos/Makefile: Don't build tools that depend on libdrm_intel

From: Robert Foss Use the HAS_INTEL automake flag to avoid building tools that won't compile unless libdrm_intel is available in the build system. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov ---

[Intel-gfx] [PACTH i-g-t v5 10/13] benchmarks/Makefile: Replace automake specific name of listing in Makfile.sources

From: Robert Foss Replace the automake specific name of listings in Makefile.sources with something not automake specific. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov --- benchmarks/Android.mk |

[Intel-gfx] [PACTH i-g-t v5 08/13] lib/stubs: Add stubs for intel_bufmgr

From: Robert Foss This patch provides stubs for functionality otherwise provided by intel_bufmgr. The stubbed functions all fail with a call to igt_require_f(false,""). Defines and enums have been copied from libdrm_intel. Due to the stubbed tests failing with an

[Intel-gfx] [PACTH i-g-t v5 09/13] demos/Makefile: Replace automake specific name of listing in Makfile.sources

From: Robert Foss Replace the automake specific name of listings in Makefile.sources with something not automake specific. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov --- demos/Android.mk | 2 +-

[Intel-gfx] [PACTH i-g-t v5 05/13] tools/Makefile: Don't build tools that depend on libdrm_intel

From: Robert Foss Use the HAS_INTEL automake flag to avoid building tools that won't compile unless libdrm_intel is available in the build system. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov ---

[Intel-gfx] [PACTH i-g-t v5 06/13] tools/Makefile: Format whitespace

From: Robert Foss Harmonize tabs/spaces etc. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov --- tools/Makefile.sources | 57 +- 1 file changed, 29

[Intel-gfx] [PACTH i-g-t v5 02/13] configure.ac: Harmonize HAVE_XXX flag for all drm platforms to HAVE_LIBDRM_XXX

From: Robert Foss Replace the automake flag HAVE_XXX for VC4/NOUVEAU with HAVE_LIBDRM_XXX in order for the flags to be more descriptive and also follow the same convention as HAVE_LIBDRM_INTEL. Signed-off-by: Robert Foss Reviewed-by: Emil

[Intel-gfx] [PACTH i-g-t v5 04/13] benchmarks/Makefile: Don't build benchmarks that depend on libdrm_intel

From: Robert Foss Use the HAS_INTEL automake flag to avoid building benchmarks that won't compile unless libdrm_intel is available in the build system. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov ---

[Intel-gfx] [PACTH i-g-t v5 03/13] Enable HAVE_LIBDRM_INTEL unconditionally for Android

From: Robert Foss Always set HAVE_LIBDRM_INTEL to true for Android targets. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov --- Android.mk | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Android.mk

[Intel-gfx] [PACTH i-g-t v5 00/13] Remove compile time depencencies on libdrm_intel

From: Robert Foss Changes since v1: - Replaced the automake flags HAVE_VC4/NOUVEAU/INTEL with HAVE_LIBDRM_XXX. - Move conditionals from Makefile.sources to Arduino.mk/Makefile.am. - Removed duplicated i915_drm.h symbols from intel_drm_stubs.h. - Replaced igt_require

[Intel-gfx] [PACTH i-g-t v5 01/13] configure.ac: Test for libdrm_intel and build for it if present

From: Robert Foss Test for libdrm_intel and build for it if present. Also expose the HAVE_INTEL #define to allow code to be conditionally compiled. Signed-off-by: Robert Foss Reviewed-by: Emil Velikov ---

Re: [Intel-gfx] [PATCH 18/31] drm/i915: Simplify request_alloc by returning the allocated request

On Wed, Jul 27, 2016 at 12:08:35PM +0100, Dave Gordon wrote: > On 25/07/16 10:18, Joonas Lahtinen wrote: > >On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: > >>If is simpler and leads to more readable code through the callstack if > >>the allocation returns the allocated struct through the

Re: [Intel-gfx] [PATCH 10/18] drm/i915: Unify legacy/execlists emission of MI_BATCHBUFFER_START

On Wed, Jul 27, 2016 at 04:04:44PM +0100, Dave Gordon wrote: > On 21/07/16 15:14, Chris Wilson wrote: > >On Thu, Jul 21, 2016 at 04:39:58PM +0300, Joonas Lahtinen wrote: > >>On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > >>> if (so.aux_batch_size > 8) { > >>>- ret =

Re: [Intel-gfx] [PATCH 10/18] drm/i915: Unify legacy/execlists emission of MI_BATCHBUFFER_START

On 21/07/16 15:14, Chris Wilson wrote: On Thu, Jul 21, 2016 at 04:39:58PM +0300, Joonas Lahtinen wrote: On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: if (so.aux_batch_size > 8) { - ret = req->engine->dispatch_execbuffer(req, -

Re: [Intel-gfx] [CI 3/5] drm/i915: Avoid using intel_engine_cs *ring for GPU error capture

On 27/07/16 09:07, Chris Wilson wrote: Inside the error capture itself, we refer to not only the hardware engine, its ringbuffer but also the capture state. Finding clear names for each whilst avoiding mixing ring/intel_engine_cs is tricky. As a compromise we keep using ering for the error

Re: [Intel-gfx] [PATCH i-g-t 06/11] lib: Update docs for igt_stats

On Wed, Jul 27, 2016 at 02:38:12PM +0200, Daniel Vetter wrote: > Unfortunately gtkdoc refuses to acknowledge static inlines, so need > to nuke them. It probably gets confused by that static ... > > Also unamed unions confuse gtk-doc, move everything else public up. Why do we bother with gtk-doc

Re: [Intel-gfx] [PATCH] drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL

On Thu, Jul 14, 2016 at 04:39:00PM +0200, Daniel Vetter wrote: > On Wed, Jul 13, 2016 at 04:32:03PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Bspec tells us to keep bashing the PCU for up to 3ms when trying to > > inform it about

Re: [Intel-gfx] [PATCH] drm/i915: Convert stray struct intel_engine_cs *ring

On 20/07/16 16:00, Chris Wilson wrote: We still have a few uses of the identifier "ring" used when referring to the struct intel_engine_cs (a remanent from when there was only one dual purpose engine/ringbuffer). Rename all of this to use the familiar engine so that the separation between the

[Intel-gfx] [PATCH i-g-t 02/11] lib: update docs for igt_debugfs

- gtk-doc requires that the names in comments match the ones in the header declaration. - igt_debugfs_dir works together with igt_sysfs_get(). Cc: Chris Wilson Signed-off-by: Daniel Vetter --- lib/igt_debugfs.c | 8 lib/igt_debugfs.h

[Intel-gfx] [PATCH i-g-t 09/11] lib: Update igt_chipset docs

gtkdoc can't handle aliasing, so let's rename the intel_device_info function. Signed-off-by: Daniel Vetter --- lib/intel_chipset.h | 54 +--- lib/intel_device_info.c | 8 +++ tools/intel_audio_dump.c | 2 +-

[Intel-gfx] [PATCH i-g-t 05/11] lib: update docs for igt_pm

- Move all the pm helpers into igt_pm.c. No idea why that wasn't done in the original commit that created igt_pm.c. - Add missing docs where needed. Cc: David Weinehall Cc: Paulo Zanoni Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH i-g-t 11/11] docs: minimal docs for igt_vgem.c

Feeling somewhat lazy right now ;-) Cc: Chris Wilson Signed-off-by: Daniel Vetter --- docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml | 1 + lib/igt_vgem.c | 12 2 files changed, 13

[Intel-gfx] [PATCH i-g-t 06/11] lib: Update docs for igt_stats

Unfortunately gtkdoc refuses to acknowledge static inlines, so need to nuke them. It probably gets confused by that static ... Also unamed unions confuse gtk-doc, move everything else public up. Cc: Chris Wilson Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH i-g-t 07/11] lib: Update igt_core docs

Just missing comment for igt_log_level. Signed-off-by: Daniel Vetter --- lib/igt_core.h | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/lib/igt_core.h b/lib/igt_core.h index 64d823f6bf48..433b88c9757c 100644 --- a/lib/igt_core.h +++

[Intel-gfx] [PATCH i-g-t 03/11] lib/debugs: nuke igt_crc_equal again

This was intentionally left out of the abi since CRC have fairly low entropy and can't be reliably compared for inequality in testcases. Spotted while fixing up warnigns in docs, but given that igt_assert_crc_equal has a big comment explaining why only the positive assert exists I'm not sure all

[Intel-gfx] [PATCH i-g-t 04/11] lib: Update docs for igt_fb

- Again match names of paramaters - structs need a typedef to work in gtk-doc - gtk-doc doesn't know about unsigned, expects unsigned int instead Cc: Paulo Zanoni --- lib/igt_fb.h | 41

[Intel-gfx] [PATCH i-g-t 01/11] lib: Update docs for igt_sysfs.c

Need to actually put it into the master .xml. Also rename the parameter names in the source with the ones in the header files to avoid confusion. gtkdoc requires that the names in the comment matches with the header. Cc: Chris Wilson Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH i-g-t 08/11] docs: pull in VC4 docs

We have them, let's use them. Cc: Eric Anholt Signed-off-by: Daniel Vetter --- docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml | 1 + lib/igt_vc4.c | 1 + 2 files changed, 2 insertions(+) diff --git

[Intel-gfx] [PATCH i-g-t 10/11] lib: Update ioctl_wrappers functions

We probably should nuke a bunch of the local_ defines again ... Signed-off-by: Daniel Vetter --- lib/ioctl_wrappers.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c index 818853ee3951..ddd71af98e04 100644 ---

[Intel-gfx] [PATCH i-g-t 00/11] igt doc updates

Unfortunately igt docs have fallen a bit to pieces the last few months. I kinda expected that Marius as the maintainer and the autobuilder would take care of catching most of this, but alas no :( I didn't fix up igt_kms since that's a real mess, and there's lots of work from Maarten and Ander in

Re: [Intel-gfx] [PATCH 21/31] drm/i915: Convert engine->write_tail to operate on a request

On Wed, Jul 27, 2016 at 12:53:25PM +0100, Dave Gordon wrote: > On 25/07/16 08:44, Chris Wilson wrote: > >+static void i9xx_submit_request(struct drm_i915_gem_request *request) > >+{ > >+struct drm_i915_private *dev_priv = request->i915; > >+ > >+I915_WRITE_TAIL(request->engine, > >+

Re: [Intel-gfx] [PATCH 21/31] drm/i915: Convert engine->write_tail to operate on a request

On Wed, Jul 27, 2016 at 12:53:25PM +0100, Dave Gordon wrote: > On 25/07/16 08:44, Chris Wilson wrote: > >If we rewrite the I915_WRITE_TAIL specialisation for the legacy > >ringbuffer as submitting the request onto the ringbuffer, we can unify > >the vfunc with both execlists and GuC in the next

Re: [Intel-gfx] [PATCH 05/11] drm/i915/tdr: Identify hung request and drop it

On Wed, Jul 27, 2016 at 12:54:44PM +0100, Arun Siluvery wrote: > On 26/07/2016 22:37, Chris Wilson wrote: > >On Tue, Jul 26, 2016 at 05:40:51PM +0100, Arun Siluvery wrote: > >>The current active request is the one that caused the hang so this is > >>retrieved and removed from elsp queue, otherwise

Re: [Intel-gfx] [PATCH 05/11] drm/i915/tdr: Identify hung request and drop it

On 26/07/2016 22:37, Chris Wilson wrote: On Tue, Jul 26, 2016 at 05:40:51PM +0100, Arun Siluvery wrote: The current active request is the one that caused the hang so this is retrieved and removed from elsp queue, otherwise we cannot submit other workloads to be processed by GPU. A consistency

Re: [Intel-gfx] [PATCH 21/31] drm/i915: Convert engine->write_tail to operate on a request

On 25/07/16 08:44, Chris Wilson wrote: If we rewrite the I915_WRITE_TAIL specialisation for the legacy ringbuffer as submitting the request onto the ringbuffer, we can unify the vfunc with both execlists and GuC in the next patch. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 03/11] drm/i915/tdr: Update reset_in_progress to account for engine reset

On 27/07/2016 12:41, Chris Wilson wrote: On Wed, Jul 27, 2016 at 12:16:04PM +0100, Arun Siluvery wrote: On 26/07/2016 22:52, Chris Wilson wrote: A totally unexplained change. If it is because you think to want to break waiters on struct_mutex, try again. So you don't want error->flags to

Re: [Intel-gfx] [PATCH 07/11] drm/i915/tdr: Add support for per engine reset recovery

On 26/07/2016 22:51, Chris Wilson wrote: On Tue, Jul 26, 2016 at 05:40:53PM +0100, Arun Siluvery wrote: This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if

Re: [Intel-gfx] [PATCH 03/11] drm/i915/tdr: Update reset_in_progress to account for engine reset

On Wed, Jul 27, 2016 at 12:16:04PM +0100, Arun Siluvery wrote: > On 26/07/2016 22:52, Chris Wilson wrote: > >A totally unexplained change. If it is because you think to want to break > >waiters on struct_mutex, try again. > So you don't want error->flags to include engine reset bits? > ok, it

Re: [Intel-gfx] [PATCHv7 5/5] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

Hi Ville, Thanks for looking at it.. > -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Wednesday, July 27, 2016 3:28 PM > To: R, Durgadoss > Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander >

Re: [Intel-gfx] [PATCH 17/31] drm/i915: Remove obsolete engine->gpu_caches_dirty

On ke, 2016-07-27 at 11:00 +0100, Chris Wilson wrote: > On Wed, Jul 27, 2016 at 10:49:46AM +0100, Dave Gordon wrote: > > > > On 25/07/16 08:44, Chris Wilson wrote: > > > > > > Space for flushing the GPU cache prior to completing the request is > > > preallocated and so cannot fail. > > > > > >

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/22] drm/i915: Combine loops within i915_gem_evict_something

== Series Details == Series: series starting with [01/22] drm/i915: Combine loops within i915_gem_evict_something URL : https://patchwork.freedesktop.org/series/10315/ State : failure == Summary == Applying: drm/i915: Combine loops within i915_gem_evict_something Using index info to

Re: [Intel-gfx] [PATCHv7 5/5] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Wednesday, July 27, 2016 3:28 PM > To: R, Durgadoss > Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander > ; Bride, Jim

[Intel-gfx] [PATCH 21/22] drm/i915: Enable lockless lookup of request tracking via RCU

If we enable RCU for the requests (providing a grace period where we can inspect a "dead" request before it is freed), we can allow callers to carefully perform lockless lookup of an active request. However, by enabling deferred freeing of requests, we can potentially hog a lot of memory when

Re: [Intel-gfx] [PATCH 17/31] drm/i915: Remove obsolete engine->gpu_caches_dirty

On 27/07/16 11:00, Chris Wilson wrote: On Wed, Jul 27, 2016 at 10:49:46AM +0100, Dave Gordon wrote: On 25/07/16 08:44, Chris Wilson wrote: Space for flushing the GPU cache prior to completing the request is preallocated and so cannot fail. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 14/22] drm/i915: Make i915_vma_pin() small and inline

Not only is i915_vma_pin() called for every single object on every single execbuf, it is usually a simple increment as the VMA is already bound for execution by the GPU. Rearrange the tests for unbound and pin_count overflow so that we can do the increment and test very cheaply and compact enough

[Intel-gfx] [PATCH 22/22] drm/i915: Export our request as a dma-buf fence on the reservation object

If the GEM objects being rendered with in this request have been exported via dma-buf to a third party, hook ourselves into the dma-buf reservation object so that the third party can serialise with our rendering via the dma-buf fences. Testcase: igt/prime_busy Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 07/22] drm/i915: Pad GTT views of exec objects up to user specified size

Our GPUs impose certain requirements upon buffers that depend upon how exactly they are used. Typically this is expressed as that they require a larger surface than would be naively computed by pitch * height. Normally such requirements are hidden away in the userspace driver, but when we accept

[Intel-gfx] [PATCH 18/22] drm/i915: Use dev_priv consistently through the intel_frontbuffer interface

Rather than a mismash of struct drm_device *dev and struct drm_i915_private *dev_priv being used freely within a function, be consistent and only pass along dev_priv. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 10

[Intel-gfx] [PATCH 19/22] drm/i915: Move obj->active:5 to obj->flags

We are motivated to avoid using a bitfield for obj->active for a couple of reasons. Firstly, we wish to document our lockless read of obj->active using READ_ONCE inside i915_gem_busy_ioctl() and that requires an integral type (i.e. not a bitfield). Secondly, gcc produces abysmal code when

Re: [Intel-gfx] [PATCH 03/11] drm/i915/tdr: Update reset_in_progress to account for engine reset

On 26/07/2016 22:52, Chris Wilson wrote: On Tue, Jul 26, 2016 at 05:40:49PM +0100, Arun Siluvery wrote: Now that we track reset progress using separate set of flags, update it to account for engine reset as well. A bit corresponding engine->id is set if reset is in progress for that engine.

[Intel-gfx] [PATCH 02/22] drm/i915: Remove surplus drm_device parameter to i915_gem_evict_something()

Eviction is VM local, so we can ignore the significance of the drm_device in the caller, and leave it to i915_gem_evict_something() to manager itself. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 3 +-- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 20/22] drm/i915: Move i915_gem_object_wait_rendering()

Just move it earlier so that we can use the companion nonblocking version in a couple of more callsites without having to add a forward declaration. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 202 1 file

[Intel-gfx] [PATCH 16/22] drm/i915: Make fb_tracking.lock a spinlock

We only need a very lightweight mechanism here as the locking is only used for co-ordinating a bitfield. v2: Move the cheap unlikely tests into the caller Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 08/22] drm/i915: Reduce WARN(i915_gem_valid_gtt_space) to a debug-only check

i915_gem_valid_gtt_space() is used after inserting the VMA to double check the list - the location should have been chosen to pass all the restrictions. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 5 + 1 file changed, 1 insertion(+), 4

[Intel-gfx] [PATCH 13/22] drm/i915: Combine all i915_vma bitfields into a single set of flags

In preparation to perform some magic to speed up i915_vma_pin(), which is among the hottest of hot paths in execbuf, refactor all the bitfields accessed by i915_vma_pin() into a single unified set of flags. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 17/22] drm/i915: Use atomics to manipulate obj->frontbuffer_bits

The individual bits inside obj->frontbuffer_bits are protected by each plane->mutex, but the whole bitfield may be accessed by multiple KMS operations simultaneously and so the RMW need to be under atomics. However, for updating the single field we do not need to mandate that it be under the

[Intel-gfx] [PATCH 04/22] drm/i915: Remove request retirement before each batch

This reimplements the denial-of-service protection against igt from commit 227f782e4667 ("drm/i915: Retire requests before creating a new one") and transfers the stall from before each batch into get_pages(). The issue is that the stall is increasing latency between batches which is detrimental in

[Intel-gfx] [PATCH 12/22] drm/i915: Start passing around i915_vma from execbuffer

During execbuffer we look up the i915_vma in order to reserve them in the VM. However, we then do a double lookup of the vma in order to then pin them, all because we lack the necessary interfaces to operate on i915_vma - so introduce i915_vma_pin()! v2: Tidy parameter lists to remove one level

[Intel-gfx] [PATCH 15/22] drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin()

Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for i915_gem_object_ggtt_pin(), spare us the confustion and remove it. Removing it now simplifies later patches to change the i915_vma_pin() (and friends) interface. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 10/22] drm/i915: Record allocated vma size

Tracking the size of the VMA as allocated allows us to dramatically reduce the complexity of later functions (like inserting the VMA in to the drm_mm range manager). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 10 ++--

[Intel-gfx] [PATCH 05/22] drm/i915: Remove i915_gem_execbuffer_retire_commands()

Move the single line to the callsite as the name is now misleading, and the purpose is solely to add the request to the execution queue. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 + 1 file changed, 1 insertion(+), 8

[Intel-gfx] [PATCH 09/22] drm/i915: Split insertion/binding of an object into the VM

Split the insertion into the address space's range manager and binding of that object into the GTT to simplify the code flow when pinning a VMA. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 35 +++ 1 file changed, 15

[Intel-gfx] Getting to RCU and exporting fences

We're starting to transition to VMA fixes now, and in the process take a few steps enabling RCU fences. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/22] drm/i915: Combine loops within i915_gem_evict_something

Slight micro-optimise to produce combine loops so that gcc is able to optimise the inner-loops concisely. Since we are reviewing the loops, we can update the comments to describe the current state of affairs, in particular the distinction between evicting from the global GTT (which may contain

[Intel-gfx] [PATCH 06/22] drm/i915: Fix up vma alignment to be u64

This is not the full fix, as we are required to percolate the u64 nature down through the drm_mm stack, but this is required now to prevent explosions due to mismatch between execbuf (eb_vma_misplaced) and vma binding (i915_vma_misplaced) - and reduces the risk of spurious changes as we adjust the

[Intel-gfx] [PATCH 03/22] drm/i915: Double check the active status on the batch pool

We should not rely on obj->active being uptodate unless we manually flush it. Instead, we can verify that the next available batch object is idle by looking at its last active request (and checking it for completion). Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 11/22] drm/i915: Wrap vma->pin_count accessors with small inline helpers

In the next few patches, the VMA pinning API is overhauled and to reduce the churn we pull out the update to the accessors into a prep patch. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c| 2 +- drivers/gpu/drm/i915/i915_gem.c

Re: [Intel-gfx] [PATCH 32/55] drm/i915: Split early global GTT initialisation

On ke, 2016-07-27 at 11:34 +0100, Chris Wilson wrote: > On Wed, Jul 27, 2016 at 01:20:42PM +0300, Joonas Lahtinen wrote: > > > > On ti, 2016-07-26 at 08:42 +0100, Chris Wilson wrote: > > > > > > On Tue, Jul 26, 2016 at 10:08:32AM +0300, Joonas Lahtinen wrote: > > > > > > > > > > > > On ma,

Re: [Intel-gfx] [PATCH 07/55] drm/i915: Avoid using intel_engine_cs *ring for GPU error capture

On ti, 2016-07-26 at 09:19 +0100, Chris Wilson wrote: > On Tue, Jul 26, 2016 at 07:59:29AM +0300, Joonas Lahtinen wrote: > > > > On ma, 2016-07-25 at 18:31 +0100, Chris Wilson wrote: > > > > > > > > Inside the error capture itself, we refer to not only the hardware > > > engine, its ringbuffer

Re: [Intel-gfx] [PATCH 18/31] drm/i915: Simplify request_alloc by returning the allocated request

On 25/07/16 10:18, Joonas Lahtinen wrote: On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote: If is simpler and leads to more readable code through the callstack if the allocation returns the allocated struct through the return value. The importance of this is that it no longer looks like we

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/31] drm/i915: Reduce breadcrumb lock coverage for intel_engine_enable_signaling() (rev3)

== Series Details == Series: series starting with [01/31] drm/i915: Reduce breadcrumb lock coverage for intel_engine_enable_signaling() (rev3) URL : https://patchwork.freedesktop.org/series/10230/ State : failure == Summary == M drivers/gpu/drm/i915/i915_gem_request.c M

Re: [Intel-gfx] [PATCH 45/55] drm/i915: Convert intel_overlay to request tracking

On ke, 2016-07-27 at 09:22 +0100, Chris Wilson wrote: > On Wed, Jul 27, 2016 at 11:12:32AM +0300, Joonas Lahtinen wrote: > > > > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote: > > > > > > -static void intel_overlay_release_old_vid_tail(struct intel_overlay > > > *overlay) > > > +static

Re: [Intel-gfx] [PATCH 43/55] drm/i915: Refactor activity tracking for requests

On ke, 2016-07-27 at 08:57 +0100, Chris Wilson wrote: > On Wed, Jul 27, 2016 at 10:40:14AM +0300, Joonas Lahtinen wrote: > > > > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote: > > > > > > @@ -172,6 +176,24 @@ static void i915_gem_request_retire(struct > > > drm_i915_gem_request *request)

[Intel-gfx] [PATCH] drm/i915: Reduce engine->emit_flush() to a single mode parameter

Rather than passing a complete set of GPU cache domains for either invalidation or for flushing, or even both, just pass a single parameter to the engine->emit_flush to determine the required operations. engine->emit_flush(GPU, 0) -> engine->emit_flush(EMIT_INVALIDATE) engine->emit_flush(0, GPU)

Re: [Intel-gfx] [PATCH 01/15] drm/i915: Add ctx getparam ioctl parameter to retrieve ctx unique id

On Wed, Jul 27, 2016 at 12:19:00PM +0200, Daniel Vetter wrote: > On Wed, Jul 27, 2016 at 02:48:38PM +0530, Deepak wrote: > > > > > > > > On 06/02/2016 10:48 AM, sourab.gu...@intel.com wrote: > > > From: Sourab Gupta > > > > > > This patch adds a new ctx getparam ioctl

Re: [Intel-gfx] [PATCH 40/55] drm/i915: Refactor blocking waits

On Wed, Jul 27, 2016 at 01:40:06PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-27 at 08:04 +0100, Chris Wilson wrote: > > On Wed, Jul 27, 2016 at 09:04:03AM +0300, Joonas Lahtinen wrote: > > > > > > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote: > > > > > > > > Tidy up the for loops

Re: [Intel-gfx] [PATCH 52/55] drm/i915: Track active vma requests

On Wed, Jul 27, 2016 at 12:47:46PM +0300, Joonas Lahtinen wrote: > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h > > b/drivers/gpu/drm/i915/i915_gem_gtt.h > > index 529fb483afc8..d2206f40f7b2 100644 > > ---

Re: [Intel-gfx] [PATCH 40/55] drm/i915: Refactor blocking waits

On ke, 2016-07-27 at 08:07 +0100, Chris Wilson wrote: > >  > > > +   active = obj->last_read; > > > +   active_mask = obj->active; > > > } else { > > > -   for (i = 0; i < I915_NUM_ENGINES; i++) { > > > -   request = i915_gem_active_peek(>last_read[i], >

Re: [Intel-gfx] [PATCH 40/55] drm/i915: Refactor blocking waits

On ke, 2016-07-27 at 08:04 +0100, Chris Wilson wrote: > On Wed, Jul 27, 2016 at 09:04:03AM +0300, Joonas Lahtinen wrote: > > > > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote: > > > > > > Tidy up the for loops that handle waiting for read/write vs read-only > > > access. > > > > > >

Re: [Intel-gfx] [PATCH 53/55] drm/i915: Release vma when the handle is closed

On Wed, Jul 27, 2016 at 01:00:59PM +0300, Joonas Lahtinen wrote: > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote: > >  /** > >   * i915_gem_wait_ioctl - implements DRM_IOCTL_I915_GEM_WAIT > >   * @dev: drm device pointer > > @@ -2810,26 +2823,32 @@ static int __i915_vma_unbind(struct

Re: [Intel-gfx] [PATCH 32/55] drm/i915: Split early global GTT initialisation

On Wed, Jul 27, 2016 at 01:20:42PM +0300, Joonas Lahtinen wrote: > On ti, 2016-07-26 at 08:42 +0100, Chris Wilson wrote: > > On Tue, Jul 26, 2016 at 10:08:32AM +0300, Joonas Lahtinen wrote: > > > > > > On ma, 2016-07-25 at 18:32 +0100, Chris Wilson wrote: > > > > > > > > -/** > > > > - *

  1   2   >