Re: [Intel-gfx] [PATCH 36/36] drm/i915: Support per-context user requests for GPU frequency control

On 3/14/2018 3:07 PM, Chris Wilson wrote: Often, we find ourselves facing a workload where the user knows in advance what GPU frequency they require for it to complete in a timely manner, and using past experience they can outperform the HW assisted RPS autotuning. An example might be kodi

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC

== Series Details == Series: series starting with [v3,01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC URL : https://patchwork.freedesktop.org/series/40170/ State : warning == Summary == $ dim checkpatch origin/drm-tip 129696d8e7f5 drm/i915/guc: Keep GuC interrupts enabled

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC

== Series Details == Series: series starting with [v3,01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC URL : https://patchwork.freedesktop.org/series/40170/ State : success == Summary == Series 40170v1 series starting with [v3,01/13] drm/i915/guc: Keep GuC interrupts enabled

Re: [Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.

Quoting Tomasz Lis (2018-03-19 12:37:35) > The patch adds a parameter to control the data port coherency functionality > on a per-exec call basis. When data port coherency flag value is different > than what it was in previous call for the context, a command to switch data > port coherency state

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Configure GPU PM in ->suspend() if not configured

== Series Details == Series: drm/i915: Configure GPU PM in ->suspend() if not configured URL : https://patchwork.freedesktop.org/series/40173/ State : success == Summary == Series 40173v1 drm/i915: Configure GPU PM in ->suspend() if not configured

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Configure GPU PM in ->suspend() if not configured

== Series Details == Series: drm/i915: Configure GPU PM in ->suspend() if not configured URL : https://patchwork.freedesktop.org/series/40173/ State : warning == Summary == Possible new issues: Test kms_vblank: Subgroup pipe-b-ts-continuation-dpms-suspend: pass

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prefer memset64() when filling the iomap

== Series Details == Series: drm/i915: Prefer memset64() when filling the iomap URL : https://patchwork.freedesktop.org/series/40180/ State : success == Summary == Series 40180v1 drm/i915: Prefer memset64() when filling the iomap

[Intel-gfx] [PATCH v2 11/13] drm/i915/guc: Default to non-verbose GuC logging

Now that we've decoupled logging from relay, GuC log level is only controlling the GuC behavior - there shouldn't be any impact on i915 behaviour. We're only going to see a single extra interrupt when log will get half full. That, and the fact that we're seeing igt/gem_exec_nop/basic-series

[Intel-gfx] [PATCH 12/13] drm/i915/guc: Demote GuC error messages

We're using those functions in selftests, and the callers are expected to do the error handling anyways. Let's demote all GuC actions and doorbell creation to DEBUG_DRIVER. Signed-off-by: Michał Winiarski Cc: Michal Wajdeczko Cc: Michel

[Intel-gfx] [PATCH 13/13] HAX enable guc for CI

--- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c96360398072..53037b5eff22 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++

Re: [Intel-gfx] [PATCH v3 10/13] drm/i915/guc: Allow user to control default GuC logging

On 3/19/2018 3:23 PM, Michał Winiarski wrote: While both naming and actual log enable logic in GuC interface are confusing, we can simply expose the default log as yet another log level. GuC logic aside, from i915 point of view we now have the following GuC log levels: 0 Log disabled

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Trim error mask to known engines

Quoting Chris Wilson (2018-03-16 21:49:59) > For the convenience of userspace passing in an arbitrary reset mask, > remove unknown engines from the set of engines that are to be reset. > This means that we always follow a per-engine reset with a full-device > reset when userspace writes -1 into

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC

== Series Details == Series: series starting with [v3,01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC URL : https://patchwork.freedesktop.org/series/40170/ State : failure == Summary == Possible new issues: Test kms_cursor_legacy: Subgroup cursor-vs-flip-legacy:

Re: [Intel-gfx] [PATCH] drm/i915/guc: Handle GuC log flush event in dedicated function

Quoting Michal Wajdeczko (2018-03-17 15:06:39) > +void intel_guc_log_handle_flush_event(struct intel_guc_log *log) > +{ > + /* Handle flush event in bottom half */ > + queue_work(log->runtime.flush_wq, >runtime.flush_work); > + > + log->flush_interrupt_count++; Document the

[Intel-gfx] [CI] drm/i915: Prefer memset64() when filling the iomap

As the ringbuffer may exist inside stolen memory, our access to it may be via the GTT iomap. This implies we may only have WC access for which the conventional memset() substitution of rep stos performs very badly, so switch to the rep mov[dq] variants when available. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v3 05/13] drm/i915/guc: Split relay control and GuC log level

Those two concepts are really separate. Since GuC is writing data into its own buffer and we even provide a way for userspace to read directly from it using i915_guc_log_dump debugfs, there's no real reason to tie log level with relay creation. Let's create a separate debugfs, giving userspace a

[Intel-gfx] [PATCH v2 04/13] drm/i915/guc: Flush directly in log unregister

Having both guc_flush_logs and guc_log_flush functions is confusing. While we could just rename things, guc_flush_logs implementation is quite simple. Let's get rid of it and move its content to unregister. v2: s/dev_priv/i915 (Sagar) Signed-off-by: Michał Winiarski

[Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.

The patch adds a parameter to control the data port coherency functionality on a per-exec call basis. When data port coherency flag value is different than what it was in previous call for the context, a command to switch data port coherency state is added before the buffer to be executed. Bspec:

[Intel-gfx] [PATCH] drm/i915/gvt: fix spelling mistake: "registeration" -> "registration"

From: Colin Ian King Trivial fix to spelling mistake in gvt_err error message text Signed-off-by: Colin Ian King --- drivers/gpu/drm/i915/gvt/gvt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH v3 10/13] drm/i915/guc: Allow user to control default GuC logging

While both naming and actual log enable logic in GuC interface are confusing, we can simply expose the default log as yet another log level. GuC logic aside, from i915 point of view we now have the following GuC log levels: 0 Log disabled 1 Non-verbose log 2-5 Verbose log

[Intel-gfx] [PATCH v3 09/13] drm/i915/guc: Don't print out relay statistics when relay is disabled

If nobody has enabled the relay, we're not comunicating with GuC, which means that the stats don't have any meaning. Let's also remove interrupt counter and tidy the debugfs formatting. v2: Correct stats accounting (Sagar) v3: Corrected one more error in stats accounting, move relay_enabled

[Intel-gfx] [PATCH 08/13] drm/i915/guc: Always print log stats in i915_guc_info when using GuC

While some of the content in this file is related to GuC submission only, that's not the case with log related statistics. Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc:

[Intel-gfx] [PATCH v2 07/13] drm/i915/guc: Get rid of GuC log runtime

Runtime is not a very good name. Let's also move counting relay overflows inside relay struct. v2: Rename things rather than remove the struct (Chris) Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio

Re: [Intel-gfx] [PATCH] drm/i915: Configure GPU PM in ->suspend() if not configured

Quoting Rushikesh S Kadam (2018-03-19 10:15:44) > The patch implements workaround for a scenario, where the GPU Power > Management, if not configured prior to platform suspend entry, will block > SoC S0ix entry in suspend-to-idle. > > Typically the GPU Power Management configuration is restored

Re: [Intel-gfx] [PATCH 12/13] drm/i915/guc: Demote GuC error messages

Quoting Michał Winiarski (2018-03-19 09:53:47) > We're using those functions in selftests, and the callers are expected > to do the error handling anyways. Let's demote all GuC actions and > doorbell creation to DEBUG_DRIVER. > > Signed-off-by: Michał Winiarski > Cc:

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC

Quoting Patchwork (2018-03-19 11:08:45) > == Series Details == > > Series: series starting with [v3,01/13] drm/i915/guc: Keep GuC interrupts > enabled when using GuC > URL : https://patchwork.freedesktop.org/series/40170/ > State : failure > > == Summary == > > Possible new issues: > >

[Intel-gfx] [PATCH v2] drm/i915/guc: Handle GuC log flush event in dedicated function

We already try to keep all GuC log related code in separate file, handling flush event should be placed there too. This will also allow future code reuse. v2: rebased Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski Cc: Sagar Arun

[Intel-gfx] [RFC v1] Data port coherency control for UMDs.

The OpenCL driver develpers requested a functionality to control cache coherency at data port level. Keeping the coherency at that level is disabled by default due to its performance costs. OpenCL driver is planning to enable it for a small subset of submissions, when such functionality is

Re: [Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on CFL and GLK

On Thu, Mar 15, 2018 at 05:42:00PM -0700, Rodrigo Vivi wrote: > On Thu, Mar 15, 2018 at 03:35:02PM +0200, David Weinehall wrote: > > Since Coffee Lake uses the Kaby Lake DMC it's a safe > > bet that the debug registers are the same. I haven't > > double-checked that the GLK DMC uses the same

Re: [Intel-gfx] [PATCH i-g-t v7] tests/perf_pmu: Improve accuracy by waiting on spinner to start

Quoting Tvrtko Ursulin (2018-03-19 13:56:05) > @@ -146,7 +198,7 @@ static int emit_recursive_batch(igt_spin_t *spin, > > /* recurse */ > fill_reloc([obj[BATCH].relocation_count], > - obj[BATCH].handle, (batch - spin->batch) + 1, > +

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add Exec param to control data port coherency.

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. URL : https://patchwork.freedesktop.org/series/40181/ State : success == Summary == Series 40181v1 drm/i915: Add Exec param to control data port coherency.

Re: [Intel-gfx] [PATCH i-g-t v7] tests/perf_pmu: Improve accuracy by waiting on spinner to start

Quoting Tvrtko Ursulin (2018-03-19 13:56:05) > @@ -443,15 +501,12 @@ most_busy_check_all(int gem_fd, const struct > intel_execution_engine2 *e, > if (!gem_has_engine(gem_fd, e_->class, e_->instance)) > continue; > > - if (e == e_) { > +

Re: [Intel-gfx] [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

On Fri, Mar 16, 2018 at 05:29:02AM -0700, Joe Perches wrote: > On Fri, 2018-03-16 at 08:41 +0100, Daniel Vetter wrote: > > On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote: > > > drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary > > > arguments that can be removed by

Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.

+ Dave, as FYI Quoting Tomasz Lis (2018-03-19 14:37:34) > The OpenCL driver develpers requested a functionality to control cache > coherency at data port level. Keeping the coherency at that level is disabled > by default due to its performance costs. OpenCL driver is planning to > enable it for

Re: [Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.

Quoting Lis, Tomasz (2018-03-19 14:14:19) > > > On 2018-03-19 13:43, Chris Wilson wrote: > > Quoting Tomasz Lis (2018-03-19 12:37:35) > >> The patch adds a parameter to control the data port coherency functionality > >> on a per-exec call basis. When data port coherency flag value is different >

[Intel-gfx] [PATCH] drm/i915/guc: Unify parameters of public CT functions

There is no need to mix parameter types in public CT functions as we can always accept intel_guc_ct. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_guc_ct.c |

[Intel-gfx] [PATCH] drm: Restore planes after load detection

From: Ville Syrjälä Actually turn the planes back on after were done with the load detection. Fixes: 20bdc112bbe4 ("drm/i915: Disable all planes for load detection, v2.") Cc: Maarten Lankhorst Cc: Daniel Vetter

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Drop union guc_log_control

On Mon, 19 Mar 2018 16:32:05 +0100, Michał Winiarski wrote: On Mon, Mar 19, 2018 at 01:49:23PM +, Michal Wajdeczko wrote: Usually we use shift/mask macros for bit field definitions. Union guc_log_control was not following that pattern. Additional bonus:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: fix spelling mistake: "registeration" -> "registration"

== Series Details == Series: drm/i915/gvt: fix spelling mistake: "registeration" -> "registration" URL : https://patchwork.freedesktop.org/series/40185/ State : success == Summary == Series 40185v1 drm/i915/gvt: fix spelling mistake: "registeration" -> "registration"

Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree

On Mon, Mar 19, 2018 at 12:29:29PM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm-misc tree got a conflict in: > > drivers/gpu/drm/i915/intel_color.c > > between commit: > > db61d160b3ed ("drm/i915: Remove the pointless 1:1 matrix copy") > > from the drm

Re: [Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.

On 2018-03-19 13:43, Chris Wilson wrote: Quoting Tomasz Lis (2018-03-19 12:37:35) The patch adds a parameter to control the data port coherency functionality on a per-exec call basis. When data port coherency flag value is different than what it was in previous call for the context, a command

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/guc: Move enable/disable msg functions to GuC header

On Mon, Mar 19, 2018 at 01:49:24PM +, Michal Wajdeczko wrote: > While today we are modifying GuC enabled msg mask only in GuC > log, this code should be defined as generic GuC to allow future > code reuse. > > Signed-off-by: Michal Wajdeczko > Cc: Michal Winiarski

[Intel-gfx] [PATCH v2 10/11] drm/i915: Extract skl_universal_plane_init()

From: Ville Syrjälä There's not much point in following the primary vs. sprite for the SKL+ universal plane init code. The only difference is of our own doing in the form of the .check_plane(). Let's make a small exception for that little detail and otherwise share

Re: [Intel-gfx] [PATCH 8/8] drm/i915/icl: Use hw engine class, instance to find irq handler

On 16/03/18 12:37, Daniele Ceraolo Spurio wrote: On 16/03/18 11:28, Michel Thierry wrote: On 3/16/2018 5:14 AM, Mika Kuoppala wrote: Interrupt identity register we already read from hardware contains engine class and instance fields. Leverage these fields to find correct engine to handle

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Unify naming of private GuC action functions

On Mon, Mar 19, 2018 at 01:49:22PM +, Michal Wajdeczko wrote: > We should avoid using guc_log prefix for functions that don't > operate on GuC log, but rather request action from the GuC. > Better to use guc_action prefix. > > v2: rebase + naming compromise > > Signed-off-by: Michal

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Prefer memset64() when filling the iomap

== Series Details == Series: drm/i915: Prefer memset64() when filling the iomap URL : https://patchwork.freedesktop.org/series/40180/ State : success == Summary == Known issues: Test kms_cursor_legacy: Subgroup 2x-long-flip-vs-cursor-legacy: fail -> PASS

Re: [Intel-gfx] [PATCH i-g-t v7] tests/perf_pmu: Improve accuracy by waiting on spinner to start

Quoting Chris Wilson (2018-03-19 15:29:21) > Quoting Tvrtko Ursulin (2018-03-19 13:56:05) > > @@ -443,15 +501,12 @@ most_busy_check_all(int gem_fd, const struct > > intel_execution_engine2 *e, > > if (!gem_has_engine(gem_fd, e_->class, e_->instance)) > >

[Intel-gfx] [PATCH v2 3/3] drm/i915/guc: Move enable/disable msg functions to GuC header

While today we are modifying GuC enabled msg mask only in GuC log, this code should be defined as generic GuC to allow future code reuse. Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski Cc: Sagar Arun Kamble

[Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Unify naming of private GuC action functions

We should avoid using guc_log prefix for functions that don't operate on GuC log, but rather request action from the GuC. Better to use guc_action prefix. v2: rebase + naming compromise Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski

[Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Drop union guc_log_control

Usually we use shift/mask macros for bit field definitions. Union guc_log_control was not following that pattern. Additional bonus: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25 (-25) Function old new delta intel_guc_log_level_set

Re: [Intel-gfx] [PATCH libdrm 0/5] improve reuse implementation

On Fri, Mar 16, 2018 at 05:10:44PM +, Emil Velikov wrote: > On 16 March 2018 at 08:43, Daniel Vetter wrote: > > On Thu, Mar 15, 2018 at 06:20:09PM -0700, James Xiong wrote: > >> From: "Xiong, James" > >> > >> With gem_reuse enabled, when a buffer size

[Intel-gfx] [PATCH i-g-t v7] tests/perf_pmu: Improve accuracy by waiting on spinner to start

From: Tvrtko Ursulin More than one test assumes that the spinner is running pretty much immediately after we have create or submitted it. In actuality there is a variable delay, especially on execlists platforms, between submission and spin batch starting to run on the

Re: [Intel-gfx] [PATCH 1/8] drm/i915/icl: Check for fused-off VDBOX and VEBOX instances

On 3/16/2018 5:44 PM, Mika Kuoppala wrote: From: Oscar Mateo In Gen11, the Video Decode engines (aka VDBOX, aka VCS, aka BSD) and the Video Enhancement engines (aka VEBOX, aka VECS) could be fused off. Also, each VDBOX and VEBOX has its own power well, which only exist

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Drop union guc_log_control

On Mon, Mar 19, 2018 at 01:49:23PM +, Michal Wajdeczko wrote: > Usually we use shift/mask macros for bit field definitions. > Union guc_log_control was not following that pattern. > > Additional bonus: > > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25 (-25) > Function

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add Exec param to control data port coherency.

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. URL : https://patchwork.freedesktop.org/series/40181/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0c30a5422174 drm/i915: Add Exec param to control data port coherency. -:54:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Handle GuC log flush event in dedicated function

== Series Details == Series: drm/i915/guc: Handle GuC log flush event in dedicated function URL : https://patchwork.freedesktop.org/series/40183/ State : success == Summary == Series 40183v1 drm/i915/guc: Handle GuC log flush event in dedicated function

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

Hi Matt, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16-rc4] [also build test ERROR on next-20180319] [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/matthew

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

== Series Details == Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC URL : https://patchwork.freedesktop.org/series/40239/ State : success == Summary == Series 40239v1 drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Add control flags to i915_handle_error()

== Series Details == Series: series starting with [1/5] drm/i915: Add control flags to i915_handle_error() URL : https://patchwork.freedesktop.org/series/40240/ State : success == Summary == Series 40240v1 series starting with [1/5] drm/i915: Add control flags to i915_handle_error()

[Intel-gfx] [PATCH v3 02/13] drm/i915/guc: Log runtime should consist of both mapping and relay

Currently, we're treating relay and mapping of GuC log as a separate concepts. We're also using inconsistent locking, sometimes using relay_lock, sometimes using struct mutex. Let's correct that. Anything touching the runtime is now serialized using runtime.lock, while we're still using struct

[Intel-gfx] [PATCH v3 01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC

The GuC log contains a separate space used for crash dump. We even get a separate notification for it. While we're not handling crash differently yet, it makes sense to decouple the two right now to simplify the following patches. v2: Move guc_log_flush_irq_disable up to avoid movement in

[Intel-gfx] [PATCH v3 03/13] drm/i915/guc: Merge log relay file and channel creation

We have all the information we need at relay_open call time. Since there's no reason to split the process into relay_open and relay_late_setup_files, let's remove the extra code. v2: Remove obsoleted comments (Sagar) v3: There was one obsolete comment left (Sagar) Signed-off-by: Michał Winiarski

[Intel-gfx] [PATCH v2 06/13] drm/i915/guc: Move check for fast memcpy_wc to relay creation

We only need those fast memcpy_wc when we're using relay to read continuous GuC log. Let's prevent the user from creating a relay if we know we won't be able to keep up with GuC. v2: Adjust the return value (Michał) Signed-off-by: Michał Winiarski Cc: Chris Wilson

[Intel-gfx] [PATCH] drm/i915: Configure GPU PM in ->suspend() if not configured

The patch implements workaround for a scenario, where the GPU Power Management, if not configured prior to platform suspend entry, will block SoC S0ix entry in suspend-to-idle. Typically the GPU Power Management configuration is restored after a platform suspend cycle, in the drm ioclts callbacks

Re: [Intel-gfx] [PATCH v3 01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC

On 3/19/2018 3:23 PM, Michał Winiarski wrote: The GuC log contains a separate space used for crash dump. We even get a separate notification for it. While we're not handling crash differently yet, it makes sense to decouple the two right now to simplify the following patches. v2: Move

Re: [Intel-gfx] [PATCH v3 01/13] drm/i915/guc: Keep GuC interrupts enabled when using GuC

On Mon, 19 Mar 2018 10:53:36 +0100, Michał Winiarski wrote: The GuC log contains a separate space used for crash dump. We even get a separate notification for it. While we're not handling crash differently yet, it makes sense to decouple the two right now to

[Intel-gfx] [PATCH i-g-t 4/5] tests/perf_pmu: Add tests for engine queued/runnable/running stats

From: Tvrtko Ursulin Simple tests to check reported queue depths are correct. Signed-off-by: Tvrtko Ursulin --- tests/perf_pmu.c | 224 +++ 1 file changed, 224 insertions(+) diff --git

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reword warning for missing cases (rev2)

== Series Details == Series: drm/i915: Reword warning for missing cases (rev2) URL : https://patchwork.freedesktop.org/series/39821/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7cb94d2c3c47 drm/i915: Reword warning for missing cases -:40: CHECK:MACRO_ARG_REUSE: Macro

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Fri, 16 Mar 2018, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities. For panels that use this

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Disable some extra clang warnings (rev2)

== Series Details == Series: drm/i915: Disable some extra clang warnings (rev2) URL : https://patchwork.freedesktop.org/series/40145/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Disable some extra clang warnings - +drivers/gpu/drm/i915/gvt/gtt.c:661:9:

[Intel-gfx] [PATCH 7/7] drm/i915: Engine queues query

From: Tvrtko Ursulin As well as exposing active requests on engines via PMU, we can also export the current raw values (as tracked by i915 command submission) via a dedicated query. This is to satisfy customers who have userspace load balancing solutions implemented on

[Intel-gfx] [PATCH 4/7] drm/i915/pmu: Add queued counter

From: Tvrtko Ursulin We add a PMU counter to expose the number of requests which have been submitted from userspace but are not yet runnable due dependencies and unsignaled fences. This is useful to analyze the overall load of the system. v2: * Rebase for name change

Re: [Intel-gfx] [PATCH] drm/i915: make GEM_WARN_ON less terrible

Quoting Matthew Auld (2018-03-19 18:08:54) > GEM_WARN_ON() was originally intended to be used only as: > >if (GEM_WARN_ON(expr)) > ... > > but it just so happens to also work as simply: > >GEM_WARN_ON(expr); > > since it just wraps WARN_ON, which is a little misleading since

[Intel-gfx] [PATCH i-g-t 0/5] Queued/runnable/running engine stats

From: Tvrtko Ursulin IGT patches for the identicaly named i915 series, including: * Engine queue depths for intel-gpu-overlay (including load average). * Tests for new PMU counters. * Tests for the query API. Tests have been tested (!) only on Skylake so YMMV. Also

[Intel-gfx] [PATCH i-g-t 5/5] tests/i915_query: Engine queues tests

From: Tvrtko Ursulin ... Signed-off-by: Tvrtko Ursulin --- tests/i915_query.c | 381 + 1 file changed, 381 insertions(+) diff --git a/tests/i915_query.c b/tests/i915_query.c index

[Intel-gfx] [PATCH i-g-t 3/5] intel-gpu-overlay: Show 1s, 30s and 15m GPU load

From: Tvrtko Ursulin Show total GPU loads in the window banner. Engine load is defined as total of runnable and running requests on an engine. Total, non-normalized, load is display. In other words if N engines are busy with exactly one request, the load will be shown

[Intel-gfx] [PATCH i-g-t 1/5] include: i915 uAPI headers

From: Tvrtko Ursulin Temporary up to date uAPI headers. Signed-off-by: Tvrtko Ursulin --- include/drm-uapi/i915_drm.h | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/include/drm-uapi/i915_drm.h

[Intel-gfx] [PATCH i-g-t 2/5] intel-gpu-overlay: Add engine queue stats

From: Tvrtko Ursulin Use new PMU engine queue stats (queued, runnable and running) and display them per engine. v2: * Compact per engine stats. (Chris Wilson) Signed-off-by: Tvrtko Ursulin --- overlay/gpu-top.c | 42

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gvt: fix spelling mistake: "registeration" -> "registration"

== Series Details == Series: drm/i915/gvt: fix spelling mistake: "registeration" -> "registration" URL : https://patchwork.freedesktop.org/series/40185/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-flip-vs-expired-vblank-interruptible:

Re: [Intel-gfx] [PATCH] drm/i915: make GEM_WARN_ON less terrible

On 19 March 2018 at 18:17, Chris Wilson wrote: > Quoting Matthew Auld (2018-03-19 18:08:54) >> GEM_WARN_ON() was originally intended to be used only as: >> >>if (GEM_WARN_ON(expr)) >> ... >> >> but it just so happens to also work as simply: >> >>

[Intel-gfx] ✗ Fi.CI.BAT: failure for Queued/runnable/running engine stats (rev3)

== Series Details == Series: Queued/runnable/running engine stats (rev3) URL : https://patchwork.freedesktop.org/series/36926/ State : failure == Summary == Series 36926v3 Queued/runnable/running engine stats https://patchwork.freedesktop.org/api/1.0/series/36926/revisions/3/mbox/

[Intel-gfx] [PATCH v4 0/7] Queued/runnable/running engine stats

From: Tvrtko Ursulin Per-engine queue depths are an interesting metric for analyzing the system load and also for users who wish to use it to load balance their submissions based on it. In this version I have split the metrics into three separate counters: 1. QUEUED -

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Reword warning for missing cases (rev2)

== Series Details == Series: drm/i915: Reword warning for missing cases (rev2) URL : https://patchwork.freedesktop.org/series/39821/ State : failure == Summary == Series 39821v2 drm/i915: Reword warning for missing cases https://patchwork.freedesktop.org/api/1.0/series/39821/revisions/2/mbox/

[Intel-gfx] [PATCH v2] drm/i915: Disable some extra clang warnings

Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set warnings to full") enabled extra warnings for i915 to spot possible bugs in new code, and then disabled a subset of these warnings to keep the current code building without warnings (with gcc). Enabling the extra warnings also

[Intel-gfx] [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

_workload_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _workload_ has been null checked. Addresses-Coverity-ID: 1430136 ("Dereference before null check") Fixes: fa3dd623e559 ("drm/i915/gvt:

[Intel-gfx] [PATCH 1/7] drm/i915/pmu: Fix enable count array size and bounds checking

From: Tvrtko Ursulin Enable count array is supposed to have one counter for each possible engine sampler. As such array sizing and bounds checking is not correct when more engine samplers are added. At the same time tidy the assert for readability and robustness.

[Intel-gfx] [PATCH 2/7] drm/i915: Keep a count of requests waiting for a slot on GPU

From: Tvrtko Ursulin Keep a per-engine number of runnable (waiting for GPU time) requests. v2: * Move queued increment from insert_request to execlist_submit_request to avoid bumping when re-ordering for priority. * Support the counter on the ringbuffer submission

[Intel-gfx] [PATCH 5/7] drm/i915/pmu: Add runnable counter

From: Tvrtko Ursulin We add a PMU counter to expose the number of requests with resolved dependencies waiting for a slot on the GPU to run. This is useful to analyze the overall load of the system. v2: Don't limit to gen8+. v3: * Rebase for dynamic sysfs. * Drop

[Intel-gfx] [PATCH 6/7] drm/i915/pmu: Add running counter

From: Tvrtko Ursulin We add a PMU counter to expose the number of requests currently executing on the GPU. This is useful to analyze the overall load of the system. v2: * Rebase. * Drop floating point constant. (Chris Wilson) v3: * Change scale to 1024 for faster

[Intel-gfx] [PATCH 3/7] drm/i915: Keep a count of requests submitted from userspace

From: Tvrtko Ursulin Keep a count of requests submitted from userspace and not yet runnable due unresolved dependencies. v2: Rename and move under the container struct. (Chris Wilson) v3: Rebase. Signed-off-by: Tvrtko Ursulin ---

[Intel-gfx] [PATCH] drm/i915: make GEM_WARN_ON less terrible

GEM_WARN_ON() was originally intended to be used only as: if (GEM_WARN_ON(expr)) ... but it just so happens to also work as simply: GEM_WARN_ON(expr); since it just wraps WARN_ON, which is a little misleading since for !DRM_I915_DEBUG_GEM builds the second case will actually

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Promote .format_mod_supported() to the lead role

== Series Details == Series: drm/i915: Promote .format_mod_supported() to the lead role URL : https://patchwork.freedesktop.org/series/40207/ State : warning == Summary == $ dim checkpatch origin/drm-tip bd9ae7d6edf8 drm/i915: Promote .format_mod_supported() to the lead role -:19:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Promote .format_mod_supported() to the lead role

== Series Details == Series: drm/i915: Promote .format_mod_supported() to the lead role URL : https://patchwork.freedesktop.org/series/40207/ State : success == Summary == Series 40207v1 drm/i915: Promote .format_mod_supported() to the lead role

Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config

On Fri, 16 Mar 2018, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > Previously it was assumed that eDP panels would advertise the lowest link > rate required for their singular mode to function. With the introduction > of more advanced features there are

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: make GEM_WARN_ON less terrible

== Series Details == Series: drm/i915: make GEM_WARN_ON less terrible URL : https://patchwork.freedesktop.org/series/40215/ State : warning == Summary == $ dim checkpatch origin/drm-tip 09aaab021f8c drm/i915: make GEM_WARN_ON less terrible -:32: ERROR:SPACING: space required after that ';'

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make GEM_WARN_ON less terrible

== Series Details == Series: drm/i915: make GEM_WARN_ON less terrible URL : https://patchwork.freedesktop.org/series/40215/ State : success == Summary == Series 40215v1 drm/i915: make GEM_WARN_ON less terrible https://patchwork.freedesktop.org/api/1.0/series/40215/revisions/1/mbox/

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915/guc: Unify naming of private GuC action functions

== Series Details == Series: series starting with [v2,1/3] drm/i915/guc: Unify naming of private GuC action functions URL : https://patchwork.freedesktop.org/series/40190/ State : success == Summary == Possible new issues: Test pm_rc6_residency: Subgroup rc6-accuracy:

[Intel-gfx] [PATCH v3 1/3] drm/i915/guc: Unify naming of private GuC action functions

We should avoid using guc_log prefix for functions that don't operate on GuC log, but rather request action from the GuC. Better to use guc_action prefix. v2: rebase + naming compromise Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski

[Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Drop union guc_log_control

Usually we use shift/mask macros for bit field definitions. Union guc_log_control was not following that pattern. Additional bonus: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25 (-25) Function old new delta intel_guc_log_level_set

[Intel-gfx] [PATCH v3 3/3] drm/i915/guc: Move enable/disable msg functions to GuC header

While today we are modifying GuC enabled msg mask only in GuC log, this code should be defined as generic GuC to allow future code reuse. Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski Cc: Sagar Arun Kamble

  1   2   >