== Series Details ==
Series: drm/i915/gen9: Fix FIFO underflows when disabling multiple outputs
URL : https://patchwork.freedesktop.org/series/10206/
State : warning
== Summary ==
Series 10206v1 drm/i915/gen9: Fix FIFO underflows when disabling multiple
outputs
http://patchwork.freedesktop.or
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 cyc
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 already
== 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:
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ä
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 37 +
1 f
== 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
http://patchwork.freedesktop.org/api/1.0/series/10149/revisions
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 of
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, avo
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 deletions(-)
diff --git a/d
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
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 +-
1 file changed, 30 insertions(+), 24
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 on
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 of
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 client
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 -
drivers/gpu/drm/i915/intel_guc.h| 6 ++
2 files changed, 2 insertion
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 01:42:55PM +0200, Daniel Vetter wrote:
> >>> These are the leftovers
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
Cc: Mali DP Maintainers
Signed-off-by: Ville Syrjälä
Acked-by: Brian St
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 them. Someone to Ack'em :-
== 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 basi
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
---
drivers/gpu/drm/i915/Makefile
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 incompatib
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 fo
== 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
http://patchwork.freedesktop.org/api/1.0/ser
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 01:0
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
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/at
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ä
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(
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ä
Reviewed-by: Joonas Lahtinen
Reviewed-by: Chris Wi
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ä
Reviewed-by: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/g
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 planes support
0|90|180|270, an
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 Clark
Signed-off-by: Ville Syrjälä
---
drivers/gpu/
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: Ville Syrjälä
---
drivers/gpu/drm/arm/malidp_planes.c | 13 +
1 file changed, 5 insert
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ä
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/
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ä
---
drivers/gpu/drm/omapdrm/omap_drv.c | 6 --
drivers/gpu/drm/omapdrm/omap_plane.c |
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ä
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-
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 ++
drivers/gpu/drm/drm_crtc.c | 18 --
drivers/gp
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 drm_plane_create_rotation_property(
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: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i9
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ä
Reviewed-by: Joonas Lahtinen
---
dr
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 BIT(DRM_ROTATE_0)
in there.
Cc: Rob Clark
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ä
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 20
1 file
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 available here:
git://github.com/v
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
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 already
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 v
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 the
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 changed, 3 insertions(+), 3 delet
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; r
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
https://lists.
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:
From:
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
Static table wastes s
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
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 testings
On Thu, Jul 21,
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 r
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 Wil
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 queues
== 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: drm/
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 us
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
---
drivers/gpu/drm/i915/i915_gem_ren
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 hangchec
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
http://patchwork.freedesktop.or
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 -
drivers/gpu/drm/i915/intel_guc.h| 6 ++
2 fi
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 l
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 +-
1 file changed, 30 inse
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 doorbe
== 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: drm/
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 in
-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 09:49:51PM +, Antoine, Peter
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) {
> > >
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 we
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: [I-G-T] igt/gem_mocs_settings
== 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
http://patchwork.freedesktop.org/api/1.0/series/10
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 handle
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 on
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)
> {
> - str
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_engine_
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: Joonas Lahtinen
---
drivers/gp
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 packet
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
drivers/gpu/drm/i915/intel_ringbuffer.h | 5 --
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:
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 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 38 ---
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
---
drivers/gpu/drm/i915/i915_gem_request.c |
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
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++--
drivers/gpu
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.
Signed-off-by:
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: Joonas Lahtinen
---
drive
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 a/drivers/gpu/drm/i915/i915_gem.c
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 +
1 file changed, 30 insertions(+), 44 deletions(-)
diff --g
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 a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drive
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 +++-
drivers/gpu/drm/i9
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 +++---
1 file changed, 3 insert
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
Reviewed-by: Joona
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 +--
2 files changed, 36 i
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 +---
drivers/gpu/drm/i915/i915_gem_gtt.c| 11 +++--
dr
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
---
drivers/gpu/drm/i915/intel_ri
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 pat
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
---
dri
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| 47 ++--
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 53 ++
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
---
drivers/gpu/drm/i915/i915_g
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 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 10 +-
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| 8 +++
drivers/gpu/drm/i915/i915_drv.h|
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 W
1 - 100 of 120 matches
Mail list logo