[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Rewrite some comments around RCU-deferred object free

== Series Details == Series: drm/i915: Rewrite some comments around RCU-deferred object free URL : https://patchwork.freedesktop.org/series/36500/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: pass ->

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915: Only attempt to scan the requested number of shrinker slabs

== Series Details == Series: series starting with [01/10] drm/i915: Only attempt to scan the requested number of shrinker slabs URL : https://patchwork.freedesktop.org/series/36501/ State : success == Summary == Series 36501v1 series starting with [01/10] drm/i915: Only attempt to scan the

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Test i915_sw_fence/dma_fence interop (rev2)

== Series Details == Series: drm/i915/selftests: Test i915_sw_fence/dma_fence interop (rev2) URL : https://patchwork.freedesktop.org/series/36493/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-indfb-draw-render: pass ->

[Intel-gfx] [PATCH 05/10] drm/i915: Trim the retired request queue after submitting

If we submit a request and see that the previous request on this timeline was already signaled, we first do not need to add the dependency tracker for that completed request and secondly we know that we there is then a large backlog in retiring requests affecting this timeline. Given that we just

[Intel-gfx] [PATCH 09/10] drm/i915: Only signal from interrupt when requested

Avoid calling dma_fence_signal() from inside the interrupt if we haven't enabled signaling on the request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 3 ++-

[Intel-gfx] [PATCH 10/10] drm/i915/breadcrumbs: Reduce signaler rbtree to a sorted list

The goal here is to try and reduce the latency of signaling additional requests following the wakeup from interrupt by reducing the list of to-be-signaled requests from an rbtree to a sorted linked list. The original choice of using an rbtree was to facilitate random insertions of request into the

[Intel-gfx] [PATCH 03/10] drm/i915: Shrink the GEM kmem_caches upon idling

When we finally decide the gpu is idle, that is a good time to shrink our kmem_caches. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 08/10] drm/i915: Move the irq_counter inside the spinlock

Rather than have multiple locked instructions inside the notify_ring() irq handler, move them inside the spinlock and reduce their intrinsic locking. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 4 ++-- drivers/gpu/drm/i915/i915_irq.c

[Intel-gfx] [PATCH 07/10] drm/i915: Reduce spinlock hold time during notify_ring() interrupt

By taking advantage of the RCU protection of the task struct, we can find the appropriate signaler under the spinlock and then release the spinlock before waking the task and signaling the fence. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 29

[Intel-gfx] [PATCH 06/10] drm/i915/breadcrumbs: Drop request reference for the signaler thread

If we remember to cancel the signaler on a request when retiring it (after we know that the request has been signaled), we do not need to carry an additional request in the signaler itself. This prevents an issue whereby the signaler threads may be delayed and hold on to thousands of request

[Intel-gfx] [PATCH 04/10] drm/i915: Shrink the request kmem_cache on allocation error

If we fail to allocate a new request, make sure we recover the pages that are in the process of being freed by inserting an RCU barrier. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Intel-gfx] Prevent trivial oom from gem_exec_nop/sequential

About the third resend of this series that tries to curtail the prolonged reference lifetimes of fences via the signaler thread when the CPUs are saturated by interrupts. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 02/10] drm/i915: Move i915_gem_retire_work_handler

In preparation for the next patch, move i915_gem_retire_work_handler() later to avoid a forward declaration. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 228 1 file changed, 114 insertions(+), 114

[Intel-gfx] [PATCH 01/10] drm/i915: Only attempt to scan the requested number of shrinker slabs

Since commit 4e773c3a8a69 ("drm/i915: Wire up shrinkctl->nr_scanned"), we track the number of objects we scan and do not wish to exceed that as it will overly penalise our own slabs under mempressure. Given that we now know the target number of objects to scan, use that as our guide for deciding

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Rewrite some comments around RCU-deferred object free

== Series Details == Series: drm/i915: Rewrite some comments around RCU-deferred object free URL : https://patchwork.freedesktop.org/series/36500/ State : success == Summary == Series 36500v1 drm/i915: Rewrite some comments around RCU-deferred object free

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use our singlethreaded wq for freeing objects

Quoting Tvrtko Ursulin (2018-01-15 16:54:57) > > On 15/01/2018 12:28, Chris Wilson wrote: > > As freeing the objects require serialisation on struct_mutex, we should > > prefer to use our singlethreaded driver wq that is dedicated to work > > requiring struct_mutex (hence serialised).The benefit

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Test i915_sw_fence/dma_fence interop (rev2)

== Series Details == Series: drm/i915/selftests: Test i915_sw_fence/dma_fence interop (rev2) URL : https://patchwork.freedesktop.org/series/36493/ State : success == Summary == Series 36493v2 drm/i915/selftests: Test i915_sw_fence/dma_fence interop

[Intel-gfx] [PATCH] drm/i915: Rewrite some comments around RCU-deferred object free

Tvrtko noticed that the comments describing the interaction of RCU and the deferred worker for freeing drm_i915_gem_object were a little confusing, so attempt to bring some sense to them. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc:

[Intel-gfx] [PATCH v2] drm/i915/selftests: Test i915_sw_fence/dma_fence interop

Check that we can successfully wait upon a dma_fence using the i915_sw_fence, including the optional timeout mechanism. v2: Account for the rounding up of the timeout to the next second. Unfortunately, the minimum delay is then 1 second. Signed-off-by: Chris Wilson Cc:

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Test i915_sw_fence/dma_fence interop

Quoting Patchwork (2018-01-15 19:31:14) > == Series Details == > > Series: drm/i915/selftests: Test i915_sw_fence/dma_fence interop > URL : https://patchwork.freedesktop.org/series/36493/ > State : failure > > == Summary == > > Test drv_selftest: > Subgroup mock_fence: >

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Test i915_sw_fence/dma_fence interop

== Series Details == Series: drm/i915/selftests: Test i915_sw_fence/dma_fence interop URL : https://patchwork.freedesktop.org/series/36493/ State : failure == Summary == Test drv_selftest: Subgroup mock_fence: pass -> INCOMPLETE (shard-snb) pass

[Intel-gfx] ✗ Fi.CI.IGT: failure for kms_plane_scaling tests.

== Series Details == Series: kms_plane_scaling tests. URL : https://patchwork.freedesktop.org/series/36485/ State : failure == Summary == Test gem_cpu_reloc: Subgroup full: pass -> DMESG-FAIL (shard-hsw) shard-hswtotal:2753 pass:1548 dwarn:1 dfail:1

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/pm_rps: Increase load for waitboosting

== Series Details == Series: igt/pm_rps: Increase load for waitboosting URL : https://patchwork.freedesktop.org/series/36452/ State : success == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 Test drv_suspend:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/36486/ State : failure == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: pass -> FAIL (shard-snb)

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: expose rcs topology through query uAPI

On 15/01/18 17:54, Tvrtko Ursulin wrote: On 15/01/2018 14:41, Lionel Landwerlin wrote: With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915/debugfs: add rcs topology entry

On 15/01/18 17:42, Tvrtko Ursulin wrote: On 15/01/2018 14:41, Lionel Landwerlin wrote: While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0: 3 subslice(s) (0x7):    

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915: store all subslice masks

On 15/01/18 17:37, Tvrtko Ursulin wrote: On 15/01/2018 14:41, Lionel Landwerlin wrote: Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymmetric (for example slice0 has different number of subslices as slice1+). This change stores

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: expose rcs topology through query uAPI

On 15/01/2018 14:41, Lionel Landwerlin wrote: With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate

Re: [Intel-gfx] [PATCH v4 4/6] drm/i915: add rcs topology to error state

On 15/01/2018 14:41, Lionel Landwerlin wrote: This might be useful information for developers looking at an error state. v2: Place topology towards the end of the error state (Chris) v3: Reuse common printing code (Michal) Signed-off-by: Lionel Landwerlin ---

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915/debugfs: add rcs topology entry

On 15/01/2018 14:41, Lionel Landwerlin wrote: While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff)

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915: store all subslice masks

On 15/01/2018 14:41, Lionel Landwerlin wrote: Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymmetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use our singlethreaded wq for freeing objects

Quoting Tvrtko Ursulin (2018-01-15 16:54:57) > > In general it is a bit funky to call_rcu to schedule worker - what would > be the difference to just queueing the worker which would have > synchronize rcu in it? The complication came from introducing the direct cleanup path to penalise frequent

Re: [Intel-gfx] [PATCH v2] drm/i915: Use the engine name directly in the error_state file

On 10/01/2018 01:21, Michel Thierry wrote: Instead of using local string names that we will have to keep maintaining, use the engine->name directly. v2: Better invalid engine_id handling, capture_bo will not be able know the engine_id and end up with -1 (Michal). Suggested-by: Michal

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [v2,1/1] meson: Refactor get_option() calls for directories (rev2)

== Series Details == Series: series starting with [v2,1/1] meson: Refactor get_option() calls for directories (rev2) URL : https://patchwork.freedesktop.org/series/36476/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-pri-indfb-draw-render:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Use our singlethreaded wq for freeing objects

== Series Details == Series: series starting with [1/2] drm/i915: Use our singlethreaded wq for freeing objects URL : https://patchwork.freedesktop.org/series/36480/ State : success == Summary == Test kms_flip: Subgroup vblank-vs-suspend: skip -> PASS

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use our singlethreaded wq for freeing objects

On 15/01/2018 12:28, Chris Wilson wrote: As freeing the objects require serialisation on struct_mutex, we should prefer to use our singlethreaded driver wq that is dedicated to work requiring struct_mutex (hence serialised).The benefit should be less clutter on the system wq, allowing it to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Test i915_sw_fence/dma_fence interop

== Series Details == Series: drm/i915/selftests: Test i915_sw_fence/dma_fence interop URL : https://patchwork.freedesktop.org/series/36493/ State : success == Summary == Series 36493v1 drm/i915/selftests: Test i915_sw_fence/dma_fence interop

[Intel-gfx] [PATCH] drm/i915/selftests: Test i915_sw_fence/dma_fence interop

Check that we can successfully wait upon a dma_fence using the i915_sw_fence, including the optional timeout mechanism. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/selftests/i915_sw_fence.c | 139

[Intel-gfx] ✓ Fi.CI.BAT: success for kms_plane_scaling tests.

== Series Details == Series: kms_plane_scaling tests. URL : https://patchwork.freedesktop.org/series/36485/ State : success == Summary == IGT patchset tested on top of latest successful build 84a308022028a55903a1916fcee516aab768ed48 tests/kms_plane: Run test for all supported pixel formats,

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/pm_rps: Increase load for waitboosting

== Series Details == Series: igt/pm_rps: Increase load for waitboosting URL : https://patchwork.freedesktop.org/series/36452/ State : success == Summary == IGT patchset tested on top of latest successful build 84a308022028a55903a1916fcee516aab768ed48 tests/kms_plane: Run test for all

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: expose RCS topology to userspace

== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/36486/ State : success == Summary == Series 36486v1 drm/i915: expose RCS topology to userspace https://patchwork.freedesktop.org/api/1.0/series/36486/revisions/1/mbox/ Test

[Intel-gfx] [PATCH v4 6/6] drm/i915: expose rcs topology through query uAPI

With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts

[Intel-gfx] [PATCH v4 5/6] drm/i915: add query uAPI

There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and slices and also which ones have been fused off for die

[Intel-gfx] [PATCH v4 4/6] drm/i915: add rcs topology to error state

This might be useful information for developers looking at an error state. v2: Place topology towards the end of the error state (Chris) v3: Reuse common printing code (Michal) Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_gpu_error.c | 9

[Intel-gfx] [PATCH v4 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

Now that we have that information in topology fields, let's just reused it. v2: Style tweaks (Tvrtko) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 27 +++

[Intel-gfx] [PATCH v4 1/6] drm/i915: store all subslice masks

Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymmetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all

[Intel-gfx] [PATCH v4 3/6] drm/i915/debugfs: add rcs topology entry

While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs

[Intel-gfx] [PATCH v4 0/6] drm/i915: expose RCS topology to userspace

Hi all, Here is another iteration on this series. Most changes are pretty cosmetic (slightly different helper in patch1, factored code in patch 3 & 4, etc...). Thanks for your feedback! Lionel Landwerlin (6): drm/i915: store all subslice masks drm/i915/debugfs: reuse max slice/subslices

[Intel-gfx] [PATCH i-g-t v3 7/8] tests/kms_plane_scaling: test scaler with clipping clamping, v3.

From: Jyoti Yadav This patch adds subtest to test scaler clipping and clamping scenario. Changes since v1: - Modify test to work with the changes to kms_plane_scaling. (Maarten) Changes since v2: - Use get_num_scalers() to skip when needed. Signed-off-by: Jyoti Yadav

[Intel-gfx] [PATCH i-g-t v3 5/8] tests/kms_plane_scaling: Clean up tests to work better with igt_kms, v2.

The test only runs on gen9+, so we can safely replace all calls with COMMIT_ATOMIC. Also perform some cleanups by making fb an array, and cleaning up in prepare_crtc. This way failed subtests won't cause failures in other subtests. Changes since v1: - Rebase on top of num_scalers changes.

[Intel-gfx] [PATCH i-g-t v3 3/8] tests/kms_plane_scaling: Convert from simple test to full test

Convert the test to run subtests per pipe, before we start adding more subtests. Signed-off-by: Maarten Lankhorst Reviewed-by: Mika Kahola --- tests/kms_plane_scaling.c | 46 +- 1 file

[Intel-gfx] [PATCH i-g-t v3 2/8] tests/kms_plane_scaling: Fix basic scaling test, v3.

From: Mahesh Kumar PIPEC doesnt have 3rd plane in GEN9. So, we skip the 3rd plane related scaling test where 2nd OVERLAY plane is not available. Restricting downscaling to (9/10)x original size of the image to avoid "Max pixel rate limitation" of the hardware. When

[Intel-gfx] [PATCH i-g-t v3 8/8] tests/kms_plane_scaling: test for multi pipe with scaling, v3.

From: Jyoti Yadav Add a subtest to display primary and overlay planes on two connected pipes and runs scaling test on both pipes Changes since v1: - Commit first before trying any scaling. (Maarten) - Use the same logic as kms_cursor_legacy to find a pipe and output.

[Intel-gfx] [PATCH i-g-t v3 4/8] tests/kms_plane_scaling: Move get_num_scalers to a function.

The number of scalers can depend on the pipe, so require at least 1 scaler before running any subtests. Signed-off-by: Maarten Lankhorst --- tests/kms_plane_scaling.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git

[Intel-gfx] [PATCH i-g-t v3 6/8] tests/kms_plane_scaling: test scaling with tiling rotation and pixel formats, v2.

From: Jyoti Yadav This patch adds subtest for testing scaling in combination with rotation and pixel formats. Changes since v1: - Rework test to work with the other changes to kms_plane_scaling. (Maarten) - Remove hardcodes for MIN/MAX_SRC_WIDTH, and use the value

[Intel-gfx] [PATCH i-g-t v3 0/8] kms_plane_scaling tests.

This series fixes the current scaler igt test failures and enhances kms_plane_scaling and kms_plane for covering subtests below: - verify all the supported pixel formats in planes - combination of rotation and scaling - combination of tiling and scaling - multi-plane/multi-pipe scaling I've

[Intel-gfx] [PATCH i-g-t v3 1/8] tests/kms_plane_scaling: Move the actual test to its own function.

We will add more subtests in the future, it's more clear if we split out the actual test to its own function first. Signed-off-by: Maarten Lankhorst Reviewed-by: Mika Kahola --- tests/kms_plane_scaling.c | 226

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/1] meson: Refactor get_option() calls for directories (rev2)

== Series Details == Series: series starting with [v2,1/1] meson: Refactor get_option() calls for directories (rev2) URL : https://patchwork.freedesktop.org/series/36476/ State : success == Summary == IGT patchset tested on top of latest successful build

[Intel-gfx] IGT news - New mailing list, switching to meson

New mailing list IGT now has its own mailing list. For a transition period, patches on both the new mailing list and intel-gfx (with the appropriate patch subjectprefix) get tested on their own respective Patchwork instances. Patches that are sent to both lists will get

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Use our singlethreaded wq for freeing objects

== Series Details == Series: series starting with [1/2] drm/i915: Use our singlethreaded wq for freeing objects URL : https://patchwork.freedesktop.org/series/36480/ State : success == Summary == Series 36480v1 series starting with [1/2] drm/i915: Use our singlethreaded wq for freeing

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add display WA #1175 for planes ending close to right screen edge

On Mon, Jan 15, 2018 at 01:26:48PM +, Chris Wilson wrote: > Quoting Imre Deak (2018-01-15 13:20:37) > > On Fri, Jan 12, 2018 at 03:01:59PM +, Chris Wilson wrote: > > > Quoting Imre Deak (2018-01-12 14:54:36) > > > > As described in the WA on GLK and CNL planes on the right edge of the > >

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Disable preemption and sleeping while using the punit sideband

Chris Wilson writes: > Quoting Mika Kuoppala (2018-01-15 12:04:40) >> Chris Wilson writes: >> >> > While we talk to the punit over its sideband, we need to prevent the cpu >> > from sleeping in order to prevent a potential machine hang. >> >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add display WA #1175 for planes ending close to right screen edge

Quoting Imre Deak (2018-01-15 13:20:37) > On Fri, Jan 12, 2018 at 03:01:59PM +, Chris Wilson wrote: > > Quoting Imre Deak (2018-01-12 14:54:36) > > > As described in the WA on GLK and CNL planes on the right edge of the > > > screen that have less than 4 pixels visible from the beginning of

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add display WA #1175 for planes ending close to right screen edge

On Fri, Jan 12, 2018 at 03:13:19PM +, Chris Wilson wrote: > Quoting Imre Deak (2018-01-12 14:54:36) > > As described in the WA on GLK and CNL planes on the right edge of the > > screen that have less than 4 pixels visible from the beginning of the > > plane to the edge of the screen can cause

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add display WA #1175 for planes ending close to right screen edge

On Fri, Jan 12, 2018 at 03:01:59PM +, Chris Wilson wrote: > Quoting Imre Deak (2018-01-12 14:54:36) > > As described in the WA on GLK and CNL planes on the right edge of the > > screen that have less than 4 pixels visible from the beginning of the > > plane to the edge of the screen can cause

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/6] drm/i915: Lock out execlist tasklet while peeking inside for busy-stats

== Series Details == Series: series starting with [v2,1/6] drm/i915: Lock out execlist tasklet while peeking inside for busy-stats URL : https://patchwork.freedesktop.org/series/36475/ State : failure == Summary == Test kms_flip: Subgroup plain-flip-fb-recreate: fail

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Disable preemption and sleeping while using the punit sideband

Hi, On 15-01-18 13:21, Chris Wilson wrote: Quoting Mika Kuoppala (2018-01-15 12:04:40) Chris Wilson writes: While we talk to the punit over its sideband, we need to prevent the cpu from sleeping in order to prevent a potential machine hang. Note that by itself, it

[Intel-gfx] ✗ Fi.CI.BAT: failure for Adding NV12 support (rev5)

== Series Details == Series: Adding NV12 support (rev5) URL : https://patchwork.freedesktop.org/series/28103/ State : failure == Summary == Series 28103v5 Adding NV12 support https://patchwork.freedesktop.org/api/1.0/series/28103/revisions/5/mbox/ Test core_auth: Subgroup basic-auth:

[Intel-gfx] [PATCH 1/2] drm/i915: Use our singlethreaded wq for freeing objects

As freeing the objects require serialisation on struct_mutex, we should prefer to use our singlethreaded driver wq that is dedicated to work requiring struct_mutex (hence serialised).The benefit should be less clutter on the system wq, allowing it to make progress even when the driver/struct_mutex

[Intel-gfx] [PATCH 2/2] drm/i915: Only attempt to scan the requested number of shrinker slabs

Since commit 4e773c3a8a69 ("drm/i915: Wire up shrinkctl->nr_scanned"), we track the number of objects we scan and do not wish to exceed that as it will overly penalise our own slabs under mempressure. Given that we now know the target number of objects to scan, use that as our guide for deciding

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Only defer freeing of fence callback when also using the timer

Quoting Patchwork (2018-01-15 10:59:15) > == Series Details == > > Series: series starting with [1/2] drm/i915: Only defer freeing of fence > callback when also using the timer > URL : https://patchwork.freedesktop.org/series/36470/ > State : success > > == Summary == > > Test

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Lock out execlist tasklet while peeking inside for busy-stats

Quoting Patchwork (2018-01-15 12:11:48) > == Series Details == > > Series: drm/i915: Lock out execlist tasklet while peeking inside for > busy-stats > URL : https://patchwork.freedesktop.org/series/36473/ > State : success > > == Logs == > > For more details see: >

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Disable preemption and sleeping while using the punit sideband

Quoting Mika Kuoppala (2018-01-15 12:04:40) > Chris Wilson writes: > > > While we talk to the punit over its sideband, we need to prevent the cpu > > from sleeping in order to prevent a potential machine hang. > > > > Note that by itself, it appears that

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Disable preemption and sleeping while using the punit sideband

Quoting Mika Kuoppala (2018-01-15 12:04:40) > Chris Wilson writes: > > > While we talk to the punit over its sideband, we need to prevent the cpu > > from sleeping in order to prevent a potential machine hang. > > > > Note that by itself, it appears that

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Lock out execlist tasklet while peeking inside for busy-stats

== Series Details == Series: drm/i915: Lock out execlist tasklet while peeking inside for busy-stats URL : https://patchwork.freedesktop.org/series/36473/ State : success == Summary == Test kms_flip: Subgroup plain-flip-fb-recreate: fail -> PASS (shard-hsw)

Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Disable preemption and sleeping while using the punit sideband

Chris Wilson writes: > While we talk to the punit over its sideband, we need to prevent the cpu > from sleeping in order to prevent a potential machine hang. > > Note that by itself, it appears that pm_qos_update_request (via > intel_idle) doesn't provide a sufficient

Re: [Intel-gfx] [PATCH i-g-t v2 8/9] lib/igt_kms: Add more braces around macros

On Fri, 2018-01-12 at 11:21 +0100, Maarten Lankhorst wrote: > The next patch wants to call for_each_pipe_with_valid_output > with *pipe and *output, this fails miserably without these braces. > Reviewed-by: Mika Kahola > Signed-off-by: Maarten Lankhorst

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Convert intel_hpd_irq_event() into an encoder hotplug hook

== Series Details == Series: series starting with [1/3] drm/i915: Convert intel_hpd_irq_event() into an encoder hotplug hook URL : https://patchwork.freedesktop.org/series/36431/ State : failure == Summary == Series 36431v1 series starting with [1/3] drm/i915: Convert intel_hpd_irq_event()

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Disable preemption and sleeping while using the punit sideband

Hi, On 15-01-18 11:28, Chris Wilson wrote: While we talk to the punit over its sideband, we need to prevent the cpu from sleeping in order to prevent a potential machine hang. Note that by itself, it appears that pm_qos_update_request (via intel_idle) doesn't provide a sufficient barrier to

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for igt/pm_rps: Increase load for waitboosting

On Sat, Jan 13, 2018 at 07:41:42PM +, Patchwork wrote: > == Series Details == > > Series: igt/pm_rps: Increase load for waitboosting > URL : https://patchwork.freedesktop.org/series/36452/ > State : failure > > == Summary == > > IGT patchset tested on top of latest successful build >

[Intel-gfx] [PATCH i-g-t v2 1/1] meson: Refactor get_option() calls for directories

Fetch the configuration values in the toplevel meson.build for all subdirs to share. v2: Also remember tests/intel-ci/meson.build Signed-off-by: Petri Latvala Cc: Daniel Vetter --- assembler/meson.build | 8 +++-

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active

On 15/01/18 12:28, Zhenyu Wang wrote: On 2018.01.15 12:07:28 +0200, Joonas Lahtinen wrote: On Fri, 2018-01-12 at 14:08 +0800, Du, Changbin wrote: On Fri, Jan 12, 2018 at 11:32:30AM +0530, Sagar Arun Kamble wrote: Is skl-gvtdvm not having vGPU active? It has flag X86_FEATURE_HYPERVISOR set

[Intel-gfx] [PATCH i-g-t 1/1] meson: Refactor get_option() calls for directories

Fetch the configuration values in the toplevel meson.build for all subdirs to share. Signed-off-by: Petri Latvala Cc: Daniel Vetter --- assembler/meson.build | 8 +++- benchmarks/meson.build | 6 -- lib/meson.build| 3 +--

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/6] drm/i915: Lock out execlist tasklet while peeking inside for busy-stats

== Series Details == Series: series starting with [v2,1/6] drm/i915: Lock out execlist tasklet while peeking inside for busy-stats URL : https://patchwork.freedesktop.org/series/36475/ State : success == Summary == Series 36475v1 series starting with [v2,1/6] drm/i915: Lock out execlist

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Only defer freeing of fence callback when also using the timer

== Series Details == Series: series starting with [1/2] drm/i915: Only defer freeing of fence callback when also using the timer URL : https://patchwork.freedesktop.org/series/36470/ State : success == Summary == Test gem_tiled_swapping: Subgroup non-threaded:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Lock out execlist tasklet while peeking inside for busy-stats

== Series Details == Series: drm/i915: Lock out execlist tasklet while peeking inside for busy-stats URL : https://patchwork.freedesktop.org/series/36473/ State : success == Summary == Series 36473v1 drm/i915: Lock out execlist tasklet while peeking inside for busy-stats

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Adding NV12 support (rev5)

Hi. > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Patchwork > Sent: maanantai 15. tammikuuta 2018 10.47 > To: Srinivas, Vidya > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✓ Fi.CI.BAT:

Re: [Intel-gfx] [PATCH 08/27] drm/i915/icl: Ringbuffer interrupt handling

On 11/01/2018 19:17, Daniele Ceraolo Spurio wrote: On 10/01/18 02:12, Chris Wilson wrote: Quoting Paulo Zanoni (2018-01-09 23:23:17) From: Tvrtko Ursulin Since it is not possible to mask individual engine instances and they are all permanently unmasked we do not

Re: [Intel-gfx] [PATCH v2 02/11] drm/i915: Lift acquiring the vlv punit magic to a common sb-get

Chris Wilson writes: > As we now employ a very heavy pm_qos around the punit access, we want to > minimise the number of synchronous requests by performing one for the > whole punit sequence rather than around individual accesses. The > sideband lock is used for this,

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/guc: Don't enable GuC when vGPU is active

On 2018.01.15 12:07:28 +0200, Joonas Lahtinen wrote: > On Fri, 2018-01-12 at 14:08 +0800, Du, Changbin wrote: > > On Fri, Jan 12, 2018 at 11:32:30AM +0530, Sagar Arun Kamble wrote: > > > Is skl-gvtdvm not having vGPU active? > > > > > > It has flag X86_FEATURE_HYPERVISOR set however it might be

[Intel-gfx] [PATCH v2 2/6] drm/i915: Disable preemption and sleeping while using the punit sideband

While we talk to the punit over its sideband, we need to prevent the cpu from sleeping in order to prevent a potential machine hang. Note that by itself, it appears that pm_qos_update_request (via intel_idle) doesn't provide a sufficient barrier to ensure that all core are indeed awake (out of

[Intel-gfx] [PATCH v2 6/6] Revert "drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3"

With the vlv sideband fixed to avoid sleeping while we talk to the punit, the system should be much more stable and be able to utilise the punit without risk. This reverts commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3") References: 6067a27d1f01 ("drm/i915:

[Intel-gfx] [PATCH v2 5/6] drm/i915: Reduce RPS update frequency on Valleyview/Cherryview

Valleyview and Cherryview update the GPU frequency via the punit, which is very expensive as we have to ensure the cores do not sleep during the comms. If we perform frequent RPS evaluations, the frequent punit requests cause measurable system overhead for little benefit, so increase the

[Intel-gfx] [PATCH v2 3/6] drm/i915: Lift acquiring the vlv punit magic to a common sb-get

As we now employ a very heavy pm_qos around the punit access, we want to minimise the number of synchronous requests by performing one for the whole punit sequence rather than around individual accesses. The sideband lock is used for this, so push the pm_qos into the sideband lock acquisition and

[Intel-gfx] [PATCH v2 4/6] drm/i915: Lift sideband locking for vlv_punit_(read|write)

Lift the sideband acquisition for vlv_punit_read and vlv_punit_write into their callers, so that we can lock the sideband once for a sequence of operations, rather than perform the heavyweight acquisition on each request. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,01/11] drm/i915: Disable preemption and sleeping while using the punit sideband

Quoting Patchwork (2018-01-15 10:23:17) > == Series Details == > > Series: series starting with [v2,01/11] drm/i915: Disable preemption and > sleeping while using the punit sideband > URL : https://patchwork.freedesktop.org/series/36469/ > State : failure > > == Summary == > > Test kms_flip:

[Intel-gfx] [PATCH v2 1/6] drm/i915: Lock out execlist tasklet while peeking inside for busy-stats

In order to prevent a race condition where we may end up overaccounting the active state and leaving the busy-stats believing the GPU is 100% busy, lock out the tasklet while we reconstruct the busy state. There is no direct spinlock guard for the execlists->port[], so we need to utilise

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,01/11] drm/i915: Disable preemption and sleeping while using the punit sideband

== Series Details == Series: series starting with [v2,01/11] drm/i915: Disable preemption and sleeping while using the punit sideband URL : https://patchwork.freedesktop.org/series/36469/ State : failure == Summary == Test kms_flip: Subgroup flip-vs-absolute-wf_vblank-interruptible:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fence: Separate timeout mechanism for awaiting on dma-fences

Quoting Chris Wilson (2018-01-15 10:15:45) > Quoting Tvrtko Ursulin (2018-01-15 10:08:01) > > If it compiles, and works, assuming we have tests cases which exercise > > both paths, then it is obviously fine. > > The no-timeout variants are using for inter-engine signaling, the > timeout variant

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fence: Separate timeout mechanism for awaiting on dma-fences

Quoting Tvrtko Ursulin (2018-01-15 10:08:01) > > On 15/01/2018 09:06, Chris Wilson wrote: > > As the timeout mechanism has grown more and more complicated, using > > multiple deferred tasks and more than doubling the size of our struct, > > split the two implementations to streamline the simpler

  1   2   >