Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/guc: use a separate GuC client for each engine

On Fri, Jul 22, 2016 at 11:23:11AM +0100, Dave Gordon wrote: > Does this patchset change the results in the parallel-submission nop test? No. Using Execlists submission Maximum execution latency on render, 3.392us, total 7.794us per cycle All (4 engines): 8,257,536 cycles, average 1.211us per

[Intel-gfx] [PATCH] drm/i915/gen9: Fix FIFO underflows when disabling multiple outputs

Currently on GEN9 if multiple outputs are disabled atomically we'll program the disabled watermark and DDB values for the 2nd, 3rd pipe to be disabled too early while the pipes are still active. Fix this by updating the watermark and DDB values only after all the selected pipes are disabled

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: Per-plane rotation etc. (rev2)

== Series Details == Series: drm: Per-plane rotation etc. (rev2) URL : https://patchwork.freedesktop.org/series/10189/ State : failure == Summary == Series 10189v2 drm: Per-plane rotation etc. http://patchwork.freedesktop.org/api/1.0/series/10189/revisions/2/mbox Test gem_exec_suspend:

[Intel-gfx] [PATCH v2 05/15] drm/atmel-hlcdc: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Propagate error upwards (Boris) Cc: Boris Brezillon Signed-off-by: Ville Syrjälä

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/guc: use one GuC client per GPU engine (rev2)

== Series Details == Series: drm/i915/guc: use one GuC client per GPU engine (rev2) URL : https://patchwork.freedesktop.org/series/10149/ State : failure == Summary == Series 10149v2 drm/i915/guc: use one GuC client per GPU engine

[Intel-gfx] [CI-Resend v2 0/6] drm/i915/guc: use one GuC client per GPU engine

When using a single GuC client for multiple engines, the i915 driver has to merge all work items into a single work queue, which the GuC firmware then demultiplexes into separate submission queues per engine. In theory, this could lead to the single queue becoming a bottleneck in which an excess

[Intel-gfx] [CI-Resend v2 1/6] drm/i915/guc: doorbell reset should avoid used doorbells

guc_init_doorbell_hw() borrows the (currently single) GuC client to use in reinitialising ALL the doorbell registers (as the hardware doesn't reset them when the GuC is reset). As a prerequisite for accommodating multiple clients, it should only reset doorbells that are supposed to be disabled,

[Intel-gfx] [NOMERGE v2 7/6] drm/i915/guc: re-enable GuC loading and submission by default

Re-enables GuC loading and submission by default on suitable platforms, since it's Intel's Plan of Record that GuC submission shall be used where available. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/guc: use one GuC client per GPU engine

On 22/07/16 11:06, Tvrtko Ursulin wrote: On 22/07/16 07:02, Patchwork wrote: == Series Details == Series: drm/i915/guc: use one GuC client per GPU engine URL : https://patchwork.freedesktop.org/series/10149/ State : success == Summary == Series 10149v1 drm/i915/guc: use one GuC client per

[Intel-gfx] [CI-Resend v2 2/6] drm/i915/guc: refactor guc_init_doorbell_hw()

We have essentially the same code in each of two different loops, so we can refactor it into a little helper function. Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_guc_submission.c | 54

[Intel-gfx] [CI-Resend v2 5/6] drm/i915/guc: use for_each_engine_id() where appropriate

Now that host structures are indexed by host engine-id rather than guc_id, we can usefully convert some for_each_engine() loops to use for_each_engine_id() and avoid multiple dereferences of engine->id. Also a few related tweaks to cache structure members locally wherever they're used more than

[Intel-gfx] [CI-Resend v2 3/6] drm/i915/guc: use a separate GuC client for each engine

When using a single GuC client for multiple engines, the i915 driver has to merge all work items into a single work queue, which the GuC firmware then demultiplexes into separate submission queues per engine. In theory, this could lead to the single queue becoming a bottleneck in which an excess

[Intel-gfx] [CI-Resend v2 4/6] drm/i915/guc: add engine mask to GuC client & pass to GuC

The Context Descriptor passed by the kernel to the GuC contains a field specifying which engine(s) the context will use. Historically, this was always set to "all of them", but now that we have one client per engine, we can be more precise, and set only the single bit for the engine that the

[Intel-gfx] [CI-Resend v2 6/6] drm/i915/guc: re-optimise i915_guc_client layout

As we're tweaking the GuC-related code in debugfs, we can drop the no-longer-used 'q_fail' and repack the structure. Signed-off-by: Dave Gordon Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 1 -

Re: [Intel-gfx] [PATCH 2/2] drm/doc: Fix more kerneldoc/sphinx warnings

Em Wed, 20 Jul 2016 20:35:09 +0200 Markus Heiser escreveu: > Am 20.07.2016 um 14:20 schrieb Mauro Carvalho Chehab > : > > > Em Tue, 19 Jul 2016 14:36:50 +0200 > > Daniel Vetter escreveu: > > > >> On Tue, Jul 19, 2016 at

Re: [Intel-gfx] [PATCH 04/15] drm/arm: Use per-plane rotation property

On Fri, Jul 22, 2016 at 04:43:05PM +0300, Ville Syrjälä wrote: From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. Cc: Liviu Dudau Cc: Brian Starkey

Re: [Intel-gfx] [PATCH] Bump libdrm-intel dependency library to a newer version that support softpin.

On 15 July 2016 at 16:42, Marius Vlad wrote: >> Side note: this will conflict with Robert Foss's work to make >> libdrm_intel an optional dependency. Have you/others had the chance to >> look at the series ? What can we do to get that moving/accepted ? > > Yes I've seen

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: Per-plane rotation etc.

== Series Details == Series: drm: Per-plane rotation etc. URL : https://patchwork.freedesktop.org/series/10189/ State : failure == Summary == Series 10189v1 drm: Per-plane rotation etc. http://patchwork.freedesktop.org/api/1.0/series/10189/revisions/1/mbox Test gem_sync: Subgroup

[Intel-gfx] [PATCH v3 1/3] drm/i915/debugfs: Move out pipe CRC code

In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. v2: Rebased. Signed-off-by: Tomeu Vizoso ---

[Intel-gfx] [PATCH v3 3/3] drm/i915: Use new CRC debugfs API

The core provides now an ABI to userspace for generation of frame CRCs, so implement the ->set_crc_source() callback and reuse as much code as possible with the previous ABI implementation. v2: - Leave the legacy implementation in place as the ABI implementation in the core is

[Intel-gfx] [PATCH v3 0/3] New debugfs API for capturing CRC of frames

Hi, this series basically takes the facility for continuously capturing CRCs of frames from the i915 driver and into the DRM core. The idea is that test suites such as IGT use this information to check that frames that are exected to be identical, also have identical CRC values. Other drivers

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/guc: use symbolic names for module parameter values

== Series Details == Series: drm/i915/guc: use symbolic names for module parameter values URL : https://patchwork.freedesktop.org/series/10188/ State : warning == Summary == Series 10188v1 drm/i915/guc: use symbolic names for module parameter values

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

On 22/07/16 13:51, Tvrtko Ursulin wrote: On 22/07/16 13:42, Dave Gordon wrote: On 21/07/16 14:46, Tvrtko Ursulin wrote: On 21/07/16 14:31, Chris Wilson wrote: On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote: On 21/07/16 13:59, Chris Wilson wrote: On Thu, Jul 21, 2016 at

Re: [Intel-gfx] [PATCH 05/15] drm/atmel-hlcdc: Use per-plane rotation property

Hi Ville, On Fri, 22 Jul 2016 16:43:06 +0300 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The global mode_config.rotation_property is going away, switch over to > per-plane rotation_property. > > Cc: Boris Brezillon

[Intel-gfx] [PATCH 09/15] drm/msm/mdp5: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. Cc: Rob Clark Cc: Jilai Wang Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 01/15] drm: Add drm_rotation_90_or_270()

From: Ville Syrjälä We have intel_rotation_90_or_270() in i915 to check if the rotation is 90 or 270 degrees. Similar checks are elsewhere in drm, so let's move the helper into a central place and use it everwhere. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 02/15] drm/atomic: Reject attempts to use multiple rotation angles at once

From: Ville Syrjälä The rotation property should only accept exactly one rotation angle at once. Let's reject attempts to set none or multiple angles. Testcase: igt/kms_rotation_crc/bad-rotation Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v2 11/15] drm/i915: Use the per-plane rotation property

From: Ville Syrjälä On certain platforms not all planes support the same set of rotations/reflections, so let's use the per-plane property for this. This is already a problem on SKL when we use the legay cursor plane as it only supports 0|180 whereas the universal

[Intel-gfx] [PATCH 07/15] drm/omap: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. Not sure I got the annoying crtc rotation_property handling right. Might work, or migth not. Cc: Tomi Valkeinen Cc: Rob

[Intel-gfx] [PATCH 04/15] drm/arm: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. Cc: Liviu Dudau Cc: Brian Starkey Cc: Mali DP Maintainers Signed-off-by:

[Intel-gfx] [PATCH 13/15] drm/i915: Use & instead if == to check for rotations

From: Ville Syrjälä Using == to check for 180 degree rotation only works as long as the reflection bits aren't set. That will change soon enough for CHV, so let's stop doing things the wrong way. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 12/15] drm: RIP mode_config->rotation_property

From: Ville Syrjälä Now that all drivers have been converted over to the per-plane rotation property, we can just nuke the global rotation property. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 6 ++

[Intel-gfx] [PATCH v2 03/15] drm: Add support for optional per-plane rotation property

From: Ville Syrjälä Not all planes on the ssytem may support the same rotations/reflections, so make it possible to create a separate property for each plane. This way userspace gets told exactly which rotations/reflections are possible for each plane. v2: Add

[Intel-gfx] [PATCH 14/15] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

From: Ville Syrjälä Move the plane control register rotation setup away from the coordinate munging code. This will result in neater looking code once we add reflection support for CHV. Signed-off-by: Ville Syrjälä Reviewed-by:

[Intel-gfx] [PATCH 06/15] drm/omap: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

From: Ville Syrjälä 0 isn't a valid rotation property value, so let's set the initial value of the property to BIT(DRM_ROTATE_0) instead. Cc: Tomi Valkeinen Cc: Rob Clark Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 05/15] drm/atmel-hlcdc: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. Cc: Boris Brezillon Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 15/15] drm/i915: Add horizontal mirroring support for CHV pipe B planes

From: Ville Syrjälä The primary and sprite planes on CHV pipe B support horizontal mirroring. Expose it to the world. Sadly the hardware ignores the mirror bit when the rotate bit is set, so we'll have to reject the 180+X case. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 10/15] drm/msm/mdp5: Advertize 180 degree rotation

From: Ville Syrjälä Since the hardware can apparently do both X and Y reflection, we can advertize also 180 degree rotation as thats just X+Y reflection. Cc: Rob Clark Cc: Jilai Wang Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 08/15] drm/msm/mdp5: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

From: Ville Syrjälä 0 isn't a valid rotation property value, so let's set the initial value of the property to BIT(DRM_ROTATE_0) instead. In the same vein, we must always have at leat one angle as part of set of supported rotation bits, so let's include

[Intel-gfx] [PATCH 00/15] drm: Per-plane rotation etc.

From: Ville Syrjälä Here's an expaned version of my earlier series [1]. This time I went as far as nuking the mode_config.rotation_property in favor of the per-plane property. Also tried to fix a few buglets in omap/msm rotation property setup. Entire series is

[Intel-gfx] [PATCH v3 0/4] drm/i915/guc: use symbolic names for module parameter values

There are various literal constants used in the GuC module-parameter processing code; this sequence of patches replaces them with symbolic names for greater clarity. And then it re-enables GuC submission by default :) v3: Original patch broken into two (1/4 + 2/4) Name for GuC log level NONE

[Intel-gfx] [PATCH v3 3/4] drm/i915/guc: symbolic name for GuC log-level none

The existing code that accesses the "guc_log_level" parameter uses an explicit numerical value for the "no logging" case, whereas there are symbolic names for the other levels. So this patch just provides and uses a name for the default log level (NONE), with the same numeric value that is

[Intel-gfx] [PATCH v3 2/4] drm/i915/guc: symbolic names for GuC firmare loading preferences

The existing code that accesses the "enable_guc_loading" parameter uses explicit numerical values for the various possibilities, including in one case relying on boolean 0/1 mapping to specific values (which could be confusing for maintainers). So this patch just provides and uses names for the

[Intel-gfx] [PATCH v3 1/4] drm/i915/guc: symbolic names for GuC submission preferences

The existing code that accesses the "enable_guc_submission" parameter uses explicit numerical values for the various possibilities, including in one case relying on boolean 0/1 mapping to specific values (which could be confusing for maintainers). So this patch just provides and uses names for

[Intel-gfx] [PATCH v3 4/4] drm/i915/guc: use symbolic names in setting defaults for module parameters

Of course, this also re-enables GuC loading and submission by default on suitable platforms, since it's Intel's Plan of Record that GuC submission shall be used where available. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_params.c | 6 +++--- 1 file

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_rotation_crc: Add bad-rotation subtest

On Fri, Jul 22, 2016 at 01:52:32PM +0100, Matthew Auld wrote: > I believe you're thinking of: > https://patchwork.freedesktop.org/patch/77191/ > https://patchwork.freedesktop.org/patch/77192/ > > Although they don't test for multiple rotation values... I guess you could just for (rotation = 0;

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_rotation_crc: Add bad-rotation subtest

I believe you're thinking of: https://patchwork.freedesktop.org/patch/77191/ https://patchwork.freedesktop.org/patch/77192/ Although they don't test for multiple rotation values... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

On 22/07/16 13:42, Dave Gordon wrote: On 21/07/16 14:46, Tvrtko Ursulin wrote: On 21/07/16 14:31, Chris Wilson wrote: On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote: On 21/07/16 13:59, Chris Wilson wrote: On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote:

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

On 21/07/16 14:46, Tvrtko Ursulin wrote: On 21/07/16 14:31, Chris Wilson wrote: On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote: On 21/07/16 13:59, Chris Wilson wrote: On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/guc: emit (drm) messages at the most appropriate level

On 22/07/16 07:25, Patchwork wrote: == Series Details == Series: drm/i915/guc: emit (drm) messages at the most appropriate level URL : https://patchwork.freedesktop.org/series/10150/ State : failure == Summary == Series 10150v1 drm/i915/guc: emit (drm) messages at the most appropriate level

Re: [Intel-gfx] [I-G-T] igt/gem_mocs_settings: improve RC6 testings

On 22/07/16 10:40, Antoine, Peter wrote: -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Friday, July 22, 2016 10:38 AM To: Antoine, Peter Cc: intel-gfx@lists.freedesktop.org Subject: Re: [I-G-T] igt/gem_mocs_settings: improve RC6

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/guc: use for_each_engine_id() where appropriate

On 22/07/16 11:04, Tvrtko Ursulin wrote: On 21/07/16 19:15, Dave Gordon wrote: Now that host structures are indexed by host engine-id rather than guc_id, we can usefully convert some for_each_engine() loops to use for_each_engine_id() and avoid multiple dereferences of engine->id. Also a few

Re: [Intel-gfx] [PATCH] drm/i915: Refactor golden render state emission to unconfuse gcc

On pe, 2016-07-22 at 11:16 +0100, Chris Wilson wrote: > GCC was inlining the init and setup functions, but was getting itself > confused into thinking that variables could be used uninitialised. If we > do the inline for gcc, it is happy! As a bonus we shrink the code. > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/guc: use a separate GuC client for each engine

On 21/07/16 19:30, Chris Wilson wrote: On Thu, Jul 21, 2016 at 07:15:39PM +0100, Dave Gordon wrote: When using a single GuC client for multiple engines, the i915 driver has to merge all work items into a single work queue, which the GuC firmware then demultiplexes into separate submission

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/18] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit (rev5)

== Series Details == Series: series starting with [01/18] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit (rev5) URL : https://patchwork.freedesktop.org/series/10090/ State : failure == Summary == Applying: drm/i915: Unify intel_logical_ring_emit and intel_ring_emit Applying:

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Drop racy markup of missed-irqs from idle-worker

On Fri, Jul 22, 2016 at 11:10:28AM +0100, Tvrtko Ursulin wrote: > > Would canceling the idle worker be to expensive? It wasn't as much as that, I was trying to keep runtime suspend simple. In that the GT takes the wakelock to prevent suspend as required and not have the knowledge about all the

[Intel-gfx] [PATCH] drm/i915: Refactor golden render state emission to unconfuse gcc

GCC was inlining the init and setup functions, but was getting itself confused into thinking that variables could be used uninitialised. If we do the inline for gcc, it is happy! As a bonus we shrink the code. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Drop racy markup of missed-irqs from idle-worker

On 21/07/16 12:04, Chris Wilson wrote: On Thu, Jul 21, 2016 at 11:28:02AM +0100, Tvrtko Ursulin wrote: On 21/07/16 11:10, Chris Wilson wrote: On Thu, Jul 21, 2016 at 10:58:05AM +0100, Tvrtko Ursulin wrote: On 21/07/16 07:57, Chris Wilson wrote: During the idle-worker we disable the

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/guc: use one GuC client per GPU engine

On 22/07/16 07:02, Patchwork wrote: == Series Details == Series: drm/i915/guc: use one GuC client per GPU engine URL : https://patchwork.freedesktop.org/series/10149/ State : success == Summary == Series 10149v1 drm/i915/guc: use one GuC client per GPU engine

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/guc: re-optimise i915_guc_client layout

On 21/07/16 19:15, Dave Gordon wrote: As we're tweaking the GuC-related code in debugfs, we can drop the now-used 'q_fail' and repack the structure. now-unused Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_debugfs.c | 1 -

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/guc: use for_each_engine_id() where appropriate

On 21/07/16 19:15, Dave Gordon wrote: Now that host structures are indexed by host engine-id rather than guc_id, we can usefully convert some for_each_engine() loops to use for_each_engine_id() and avoid multiple dereferences of engine->id. Also a few related tweaks to cache structure members

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: refactor guc_init_doorbell_hw()

On 21/07/16 19:15, Dave Gordon wrote: We have essentially the same code in each of two different loops, so we can refactor it into a little helper function. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 54

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915/guc: doorbell reset should avoid used doorbells

On 21/07/16 19:15, Dave Gordon wrote: guc_init_doorbell_hw() borrows the (currently single) GuC client to use in reinitialising ALL the doorbell registers (as the hardware doesn't reset them when the GuC is reset). As a prerequisite for accommodating multiple clients, it should only reset

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/18] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit (rev4)

== Series Details == Series: series starting with [01/18] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit (rev4) URL : https://patchwork.freedesktop.org/series/10090/ State : failure == Summary == Applying: drm/i915: Unify intel_logical_ring_emit and intel_ring_emit Applying:

Re: [Intel-gfx] [PATCH 16/18] drm/i915: Remove duplicate golden render state init from execlists

On to, 2016-07-21 at 17:37 +0100, Chris Wilson wrote: > On Thu, Jul 21, 2016 at 05:27:06PM +0100, Chris Wilson wrote: > > > > On Thu, Jul 21, 2016 at 05:18:17PM +0300, Joonas Lahtinen wrote: > > > > > > On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > > > > > > > >  static const struct

Re: [Intel-gfx] [I-G-T] igt/gem_mocs_settings: improve RC6 testings

-Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Friday, July 22, 2016 10:38 AM To: Antoine, Peter Cc: intel-gfx@lists.freedesktop.org Subject: Re: [I-G-T] igt/gem_mocs_settings: improve RC6 testings On Thu, Jul 21, 2016 at

Re: [Intel-gfx] [PATCH 15/18] drm/i915/ringbuffer: Specialise SNB+ request emission for semaphores

On to, 2016-07-21 at 15:10 +0100, Chris Wilson wrote: > On Thu, Jul 21, 2016 at 04:55:00PM +0300, Joonas Lahtinen wrote: > > > > On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > > > + engine->emit_request = gen6_sema_emit_request; > > > + > > >   if (INTEL_GEN(dev_priv) >= 8) { > > >  

Re: [Intel-gfx] [PATCH] drm/i915: Rename engine->semaphore.sync_to, engine->sempahore.signal locals

On pe, 2016-07-22 at 10:31 +0100, Chris Wilson wrote: > On Fri, Jul 22, 2016 at 12:28:11PM +0300, Joonas Lahtinen wrote: > > > > On pe, 2016-07-22 at 10:14 +0100, Chris Wilson wrote: > > > > > >   /* When the !RCS engines idle waiting upon a semaphore, they lose their > > >    * pagetables and

Re: [Intel-gfx] [I-G-T] igt/gem_mocs_settings: improve RC6 testings

On Thu, Jul 21, 2016 at 09:49:51PM +, Antoine, Peter wrote: > > > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Thursday, July 21, 2016 9:40 PM > To: Antoine, Peter > Cc: intel-gfx@lists.freedesktop.org > Subject: Re:

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v2,01/25] drm/i915/cmdparser: Remove stray intel_engine_cs *ring

== Series Details == Series: series starting with [v2,01/25] drm/i915/cmdparser: Remove stray intel_engine_cs *ring URL : https://patchwork.freedesktop.org/series/10177/ State : failure == Summary == Series 10177v1 Series without cover letter

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

On Fri, Jul 22, 2016 at 06:47:28AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Correctly handle limited range YCbCr data on VLV/CHV > URL : https://patchwork.freedesktop.org/series/10154/ > State : failure > > == Summary == > > Series 10154v1 drm/i915: Correctly

Re: [Intel-gfx] [PATCH] drm/i915: Rename engine->semaphore.sync_to, engine->sempahore.signal locals

On Fri, Jul 22, 2016 at 12:28:11PM +0300, Joonas Lahtinen wrote: > On pe, 2016-07-22 at 10:14 +0100, Chris Wilson wrote: > >   /* When the !RCS engines idle waiting upon a semaphore, they lose their > >    * pagetables and we must reload them before executing the batch. > >    * We do this

Re: [Intel-gfx] [PATCH] drm/i915: Rename engine->semaphore.sync_to, engine->sempahore.signal locals

On pe, 2016-07-22 at 10:14 +0100, Chris Wilson wrote: >  static int > -gen8_ring_sync(struct drm_i915_gem_request *wait, > -    struct drm_i915_gem_request *signal) > +gen8_ring_sync_to(struct drm_i915_gem_request *req, > +   struct drm_i915_gem_request *signal) >  { > -

Re: [Intel-gfx] [PATCH v2 19/25] drm/i915/lrc: Update function names to match request flow

On pe, 2016-07-22 at 10:03 +0100, Chris Wilson wrote: > With adding engine->submit_request, we now have a bunch of functions > with similar names used at different stages of the execlist submission. > Try a different coat of paint, to hopefully reduce confusion between the > requests,

[Intel-gfx] [PATCH] drm/i915: Rename engine->semaphore.sync_to, engine->sempahore.signal locals

In order to be more consistent with the rest of the request construction and ring emission, use the common names for the ring and request. Rather than using signaler_req, waiter_req, and intel_ring *wait, we use plain req and ring. Signed-off-by: Chris Wilson Cc:

Re: [Intel-gfx] [PATCH 13/18] drm/i915: Stop passing caller's num_dwords to engine->semaphore.signal()

On pe, 2016-07-22 at 09:30 +0100, Chris Wilson wrote: > On Fri, Jul 22, 2016 at 11:15:59AM +0300, Joonas Lahtinen wrote: > > > > On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > > > > > > Rather than pass in the num_dwords that the caller wishes to use after > > > the signal command

[Intel-gfx] [PATCH v2 16/25] drm/i915: Remove intel_ring_get_tail()

Joonas doesn't like the tiny function, especially if I go around making it more complicated and using it elsewhere. To remove that temptation, remove the function! Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 8

[Intel-gfx] [PATCH v2 12/25] drm/i915: Rename intel_pin_and_map_ring()

For more consistent oop-naming, we would use intel_ring_verb, so pick intel_ring_pin() and intel_ring_unpin(). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_lrc.c| 4 ++--

[Intel-gfx] [PATCH v2 17/25] drm/i915: Convert engine->write_tail to operate on a request

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 Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 25/25] drm/i915: Simplify calling engine->sync_to

Since requests can no longer be generated as a side-effect of intel_ring_begin(), we know that the seqno will be unchanged during ring-emission. This predicatablity then means we do not have to check for the seqno wrapping around whilst emitting the semaphore for engine->sync_to(). Signed-off-by:

[Intel-gfx] [PATCH v2 15/25] drm/i915: Unify legacy/execlists emission of MI_BATCHBUFFER_START

Both the ->dispatch_execbuffer and ->emit_bb_start callbacks do exactly the same thing, add MI_BATCHBUFFER_START to the request's ringbuffer - we need only one vfunc. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH v2 19/25] drm/i915/lrc: Update function names to match request flow

With adding engine->submit_request, we now have a bunch of functions with similar names used at different stages of the execlist submission. Try a different coat of paint, to hopefully reduce confusion between the requests, intel_engine_cs and the actual execlists submision process.

[Intel-gfx] [PATCH v2 11/25] drm/i915: Rename residual ringbuf parameters

Now that we have a clear ring/engine split and a struct intel_ring, we no longer need the stopgap ringbuf names. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 66 - drivers/gpu/drm/i915/intel_ringbuffer.h | 6

[Intel-gfx] [PATCH v2 13/25] drm/i915: Remove obsolete engine->gpu_caches_dirty

Space for flushing the GPU cache prior to completing the request is preallocated and so cannot fail. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c| 2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 +---

[Intel-gfx] [PATCH v2 18/25] drm/i915: Unify request submission

Move request submission from emit_request into its own common vfunc from i915_add_request(). v2: Convert I915_DISPATCH_flags to BIT(x) whilst passing v3: Rename a few functions to match. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c| 8

[Intel-gfx] [PATCH v2 05/25] drm/i915: Update a couple of hangcheck comments to talk about engines

We still have lots of comments that refer to the old ring when we mean struct intel_engine_cs and its hardware correspondence. This patch fixes an instance inside hangcheck to talk about engines. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 6

[Intel-gfx] [PATCH v2 24/25] drm/i915: Unify legacy/execlists submit_execbuf callbacks

Now that emitting requests is identical between legacy and execlists, we can use the same function to build up the ring for submitting to either engine. (With the exception of i915_switch_contexts(), but in time that will also be handled gracefully.) Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v2 23/25] drm/i915: Remove duplicate golden render state init from execlists

Now that we use the same vfuncs for emitting the batch buffer in both execlists and legacy, the golden render state initialisation is identical between both. v2: gcc wants so.ggtt_offset initialised (even though it is not used) Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH v2 04/25] drm/i915: Remove stray intel_engine_cs ring identifiers from i915_gem.c

A few places we use ring when referring to the struct intel_engine_cs. An anachronism we are pruning out. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git

[Intel-gfx] [PATCH v2 21/25] drm/i915: Reuse legacy breadcrumbs + tail emission

As GEN6+ is now a simple variant on the basic breadcrumbs + tail write, reuse the common code. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_ringbuffer.c | 74 +

[Intel-gfx] [PATCH v2 08/25] drm/i915: Rename backpointer from intel_ringbuffer to intel_engine_cs

Having ringbuf->ring point to an engine is confusing, so rename it once again to ring->engine. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

[Intel-gfx] [PATCH v2 22/25] drm/i915/ringbuffer: Specialise SNB+ request emission for semaphores

As gen6_emit_request() only differs from i9xx_emit_request() when semaphores are enabled, only use the specialised vfunc in that scenario. v2: Reorder semaphore init so as to keep engine->emit_request default vfunc selection compact. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH v2 20/25] drm/i915: Stop passing caller's num_dwords to engine->semaphore.signal()

Rather than pass in the num_dwords that the caller wishes to use after the signal command packet, split the breadcrumb emission into two phases and have both the signal and breadcrumb individiually acquire space on the ring. This makes the interface simpler for the reader, and will simplify for

[Intel-gfx] [PATCH v2 03/25] drm/i915: Avoid using intel_engine_cs *ring for GPU error capture

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 capture. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v2 06/25] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit

Both perform the same actions with more or less indirection, so just unify the code. v2: Add back a few intel_engine_cs locals Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_context.c|

[Intel-gfx] [PATCH v2 07/25] drm/i915: Rename request->ringbuf to request->ring

Now that we have disambuigated ring and engine, we can use the clearer and more consistent name for the intel_ringbuffer pointer in the request. @@ struct drm_i915_gem_request *r; @@ - r->ringbuf + r->ring Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 01/25] drm/i915/cmdparser: Remove stray intel_engine_cs *ring

When we refer to intel_engine_cs, we want to use engine so as not to confuse ourselves about ringbuffers. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/i915_drv.h | 5 +++--

[Intel-gfx] [PATCH v2 10/25] drm/i915: Rename struct intel_ringbuffer to struct intel_ring

The state stored in this struct is not only the information about the buffer object, but the ring used to communicate with the hardware. Using buffer here is overly specific and, for me at least, conflates with the notion of buffer objects themselves. s/struct intel_ringbuffer/struct intel_ring/

[Intel-gfx] [PATCH v2 09/25] drm/i915: Rename intel_context[engine].ringbuf

Perform s/ringbuf/ring/ on the context struct for consistency with the ring/engine split. v2: Kill an outdated error_ringbuf label Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_debugfs.c

[Intel-gfx] [PATCH v2 14/25] drm/i915: Simplify request_alloc by returning the allocated request

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 accidentally allocate requests as side-effect of calling certain functions. Signed-off-by: Chris

  1   2   >