This was caused by a silent merge conflict, and is now fixed.
Regards, Joonas
Quoting kbuild test robot (2019-05-07 13:53:48)
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: 73db4ec12f05160528884c0b2c845b1c6b7c6718
> commit: b9a2acf7709f52c77dc752ec99e3873e392d8df6 [5/8] Mer
This too was caused by a merge conflict and one missing Fixes:.
Regards, Joonas
Quoting kbuild test robot (2019-05-07 14:08:25)
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: ae28cc6cf80a2e8cbb58f255ef7cac6b2923c98a
> commit: 47f4a14297839cb4cedd725fb916a5da5eb9b5ba [/8] Me
On Wed, May 8, 2019 at 9:53 AM Sergey Senozhatsky
wrote:
>
> On (05/08/19 16:44), Sergey Senozhatsky wrote:
> > [..]
> > > static void native_smp_send_reschedule(int cpu)
> > > {
> > > if (unlikely(cpu_is_offline(cpu))) {
> > > - WARN(1, "sched: Unexpected reschedule of offline CPU
Currently the code for manipulating the pages on an object is still
residing in i915_gem.c, move it to i915_gem_object.c
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 4 +-
.../gpu/drm/i915/{ => gem}/i915_gem_obj
In the next patch, we will want to configure the slave request
depending on which physical engine the master request is executed on.
For this, we introduce a callback from the execute fence to convey this
information.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i
In the unlikely case the request completes while we regard it as not even
executing on the GPU (see the next patch!), we have to flush any pending
execution callbacks at retirement and ensure that we do not add any
more.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 93 ++
Allow the user to direct which physical engines of the virtual engine
they wish to execute one, as sometimes it is necessary to override the
load balancing algorithm.
v2: Only kick the virtual engines on context-out if required
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm
To continue the onslaught of removing the assumption of a global
execution ordering, another casualty is the engine->timeline. Without an
actual timeline to track, it is overkill and we can replace it with a
much less grand plain list. We still need a list of requests inflight,
for the simple purpo
Split the plain old shmem object into its own file to start decluttering
i915_gem.c
v2: Lose the confusing, hysterical raisins, suffix of _gtt.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ob
Continuing the theme of separating out the GEM clutter.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 26 +--
drivers/gpu/drm/i915/Makefile.header-test | 2 -
.../gpu/drm/i915/{ => gem}/i915_gem_clflush.c | 27 +++
drivers/gpu/drm/i915/gem/i
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load.
The handling of the no-preemption priority level imposes the restriction
that we need to maintain the implied ordering even though preemption is
disabled. Otherwise we may end up with an AB-BA deadlock across multiple
engine due to a real preemption event reordering the no-preemption
WAITs. To reso
Having hid the partially exposed new ABI from the PR, put it back again
for completion of context recovery. A significant part of context
recovery is the ability to reuse as much of the old context as is
feasible (to avoid expensive reconstruction). The biggest chunk kept
hidden at the moment is fi
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES.
This will be useful for setting SSEU parameters on virtual engines that
are local to the context
To avoid pulling in a forward declaration in the next patch, move the
i915_sched_node handling to after the main dfs of the scheduler.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 210 +-
1 file changed, 105 insertio
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with a
When using a global seqno, we required a precise stop-the-workd event to
handle preemption and unwind the global seqno counter. To accomplish
this, we would preempt to a special out-of-band context and wait for the
machine to report that it was idle. Given an idle machine, we could very
precisely s
After realising we need to sample RING_START to detect context switches
from preemption events that do not allow for the seqno to advance, we
can also realise that the seqno itself is just a distance along the ring
and so can be replaced by sampling RING_HEAD.
Signed-off-by: Chris Wilson
Cc: Mika
To simplify the next patch, update bump_priority and schedule to accept
the internal i915_sched_ndoe directly and not expect a request pointer.
add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7)
Function old new delta
i915_schedule_bump_priority
On Wed, May 8, 2019 at 9:53 AM Sergey Senozhatsky
wrote:
>
> On (05/08/19 16:44), Sergey Senozhatsky wrote:
> > [..]
> > > static void native_smp_send_reschedule(int cpu)
> > > {
> > > if (unlikely(cpu_is_offline(cpu))) {
> > > - WARN(1, "sched: Unexpected reschedule of offline CPU
Continuing the decluttering of i915_gem.c, now the turn of do_mmap and
the faulthandlers
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 505
drivers/gpu/drm/i915/ge
For convenience in avoiding inline spaghetti, keep the type definition
as a separate header.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/Makefile | 1 +
drivers/gpu/drm/i915/gem/Makefile.
Continuing the decluttering of i915_gem.c, that of the read/write
domains, perhaps the biggest of GEM's follies?
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 784 +
Currently there is an underlying assumption that i915_request_unsubmit()
is synchronous wrt the GPU -- that is the request is no longer in flight
as we remove it. In the near future that may change, and this may upset
our signaling as we can process an interrupt for that request while it
is no long
In all likelihood, the priority and node are already in the CPU cache
and by checking them first, we can avoid having to chase the
*request->hwsp for the current breadcrumb.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 4 ++--
1 file changed, 2 inse
Use the per-object local lock to control the cache domain of the
individual GEM objects, not struct_mutex. This is a huge leap forward
for us in terms of object-level synchronisation; execbuffers are
coordinated using the ww_mutex and pread/pwrite is finally fully
serialised again.
Signed-off-by:
Move the duplicated code within dma-fence.c into the header for wider
reuse.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile| 10 +-
drivers/dma-buf/dma-fence-trace.c | 28 +++
drivers/dma-buf/dma-fence.c | 28 +--
drivers/gpu/drm/i915/gt
Some users require that when a master batch is executed on one particular
engine, a companion batch is run simultaneously on a specific slave
engine. For this purpose, we introduce virtual engine bonding, allowing
maps of master:slaves to be constructed to constrain which physical
engines a virtual
Declutter i915_drv/gem.h by moving the ioctl API into its own header.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 52 ++
drivers/gpu/drm/i915/i915_drv.c| 1 +
drivers/gpu/drm/i915/i915_drv.h|
Out scatterlist utility routines can be pulled out of i915_gem.h for a
bit more decluttering.
v2: Push I915_GTT_PAGE_SIZE out of i915_scatterlist itself and into the
caller.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers
A usecase arose out of handling context recovery in mesa, whereby they
wish to recreate a context with fresh logical state but preserving all
other details of the original. Currently, they create a new context and
iterate over which bits they want to copy across, but it would much more
convenient i
Continuing the decluttering of i915_gem.c, this time the legacy physical
object.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 2 +
drivers/gpu/drm/i915/gem/i915_gem_object.h| 11 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h
Use i915_gem_object_lock() to guard the LUT and active reference to
allow us to break free of struct_mutex for handling GEM_CLOSE.
Testcase: igt/gem_close_race
Testcase: igt/gem_exec_parallel
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 76 ++-
Remove the modification of the "constant" device info by promoting the
inconsistent intel_engine static table into an initialisation error.
Now, if we add a new engine into the device_info, we must first add that
engine information into the intel_engines.
Signed-off-by: Chris Wilson
---
drivers/
An old optimisation to reduce the number of atomics per batch sadly
relies on struct_mutex for coordination. In order to remove struct_mutex
from serialising object/context closing, always taking and releasing an
active reference on first use / last use greatly simplifies the locking.
Signed-off-b
There is a desire to split a task onto two engines and have them run at
the same time, e.g. scanline interleaving to spread the workload evenly.
Through the use of the out-fence from the first execbuf, we can
coordinate secondary execbuf to only become ready simultaneously with
the first, so that w
On Mon, May 06, 2019 at 01:24:48PM +0200, Petr Mladek wrote:
> On Mon 2019-05-06 11:38:13, Daniel Vetter wrote:
> > On Mon, May 06, 2019 at 10:26:28AM +0200, Petr Mladek wrote:
> > > On Mon 2019-05-06 10:16:14, Petr Mladek wrote:
> > > > On Mon 2019-05-06 09:45:53, Daniel Vetter wrote:
> > > > > co
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
forYCbCr4
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to 1.5.
SDP VSC Header and Data Block follow DP 1.4a spec, section 2.2.5.7.5,
chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
include/drm/drm_dp_helper.h | 17 +
1 file changed, 17 insertions(+)
diff --g
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 fi
On Wed, May 8, 2019 at 9:44 AM Sergey Senozhatsky
wrote:
>
> On (05/07/19 19:33), Daniel Vetter wrote:
> [..]
> > - make the console_trylock trylock also the spinlock. This works in
> > the limited case of the console_lock use-case, but doesn't fix the
> > same semaphore.lock acquisition in th
The SINGLE_TIMELINE flag can be used to create a context such that all
engine instances within that context share a common timeline. This can
be useful for mixing operations between real and virtual engines, or
when using a composite context for a single client API context.
Signed-off-by: Chris Wi
Continuing the decluttering of i915_gem.c by moving the object wait
decomposition into its own file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 +
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 277 ++
Continuing the decluttering of i915_gem.c by moving the object busy
checking into its own file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 138 +++
drivers/gpu/drm/i915/i915_gem.c | 128
Continuing the decluttering of i915_gem.c by moving the client self
throttling into its own file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/gem/i915_gem_throttle.c | 74
drivers/gpu/drm/i915/i915_drv.h
We no longer track the execution order along the engine and so no longer
need to enforce ordering of retire along the engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 128 +++-
1 file changed, 52 insertions(+), 76 deletions(-)
diff --git a/dr
If we have multiple contexts of equal priority pending execution,
activate a timer to demote the currently executing context in favour of
the next in the queue when that timeslice expires. This enforces
fairness between contexts (so long as they allow preemption -- forced
preemption, in the future,
Rename the engine this HW context is currently active upon (that we are
flying upon) to disambiguate between the mixture of different active
terms (and prevent conflict in future patches).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +-
drivers/gpu/drm/i915
We need to keep the context image pinned in memory until after the GPU
has finished writing into it. Since it continues to write as we signal
the final breadcrumb, we need to keep it pinned until the request after
it is complete. Currently we know the order in which requests execute on
each engine,
On 07/05/2019 17:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-04-29 15:12:23)
On 25/04/2019 10:19, Chris Wilson wrote:
static void virtual_submission_tasklet(unsigned long data)
{
struct virtual_engine * const ve = (struct virtual_engine *)data;
const int prio = ve
On Wed, 08 May 2019, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
For i915
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, May 7, 2019 5:40 PM
>To: Shankar, Uma
>Cc: Jonas Karlman ; intel-gfx@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; seanp...@chromium.org; emil.l.veli...@gmail.com;
>dcasta...@chrom
On Wed, May 08, 2019 at 05:01:44PM +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c
From: Alastair D'Silva
> Sent: 08 May 2019 08:02
> To: alast...@d-silva.org
...
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -480,13 +480,13 @@ enum {
> DUMP_PREFIX_OFFSET
> };
>
> -extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
> -
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, May 7, 2019 5:32 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ; emil.l.veli...@gmail
Add a new mode for some more stress, submit the all-engines tests
simultaneously, a stream per engine.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/tests/i915/gem_exec_whisper.c b/te
The submit-fence + load_balancing apis allow for us to execute a named
pair of engines in parallel; that this by submitting a request to one
engine, we can then use the generated submit-fence to submit a second
request to another engine and have it execute at the same time.
Furthermore, by specifyi
Measure the baseline latency between contexts in order to directly
compare that with the additional cost of preemption.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 230 ++
1 file changed, 230 insertions(+)
diff --git a/tests/i915/gem_exec_late
commit 53073249452d307b66c2ab9a4b5ebf94db534ad6
Author: Chris Wilson
Date: Thu Jan 25 17:55:58 2018 +
drm/i915: Allow contexts to share a single timeline across all engines
Signed-off-by: Chris Wilson
---
include/drm-uapi/i915_drm.h | 18 +-
1 file changed, 17 inserti
Queues are a form of contexts that share vm and enfore a single timeline
across all engines. Test switching between them, just like ordinary
contexts.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_switch.c | 75 +++--
1 file changed, 55 insertions(+), 20 dele
Exercise reusing the GTT of one ctx in another.
v2: Test setting back to the same VM
v3: Check the VM still exists after the parent ctx are dead.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_ctx_param.c | 107 -
1 file changed, 95 insert
commit 364df3d04d51f0aad13b898f3dffca8c2d03d2b3 (HEAD)
Author: Chris Wilson
Date: Fri Jun 30 13:40:53 2017 +0100
drm/i915: Allow specification of parallel execbuf
Signed-off-by: Chris Wilson
---
include/drm-uapi/i915_drm.h | 146 +++-
1 file changed, 145 i
We removed next_seqno in 5.1, so time to wave goodbye.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_whisper.c | 12
1 file changed, 12 deletions(-)
diff --git a/tests/i915/gem_exec_whisper.c b/tests/i915/gem_exec_whisper.c
index d5afc8119..61b8d6dac 100644
--- a/tests/i915/g
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 81 +++
1 file changed, 81 insertions(+)
diff --git a/tests/i915/gem_exec_latency.c b/tests/i915/gem_exec_latency.c
index e88fbbc6a..fd4ceb4d6 100644
--- a/tests/i915/gem_exec_latency.c
+++ b/tests/i9
Exercise cloning contexts, an extension of merely creating one.
Signed-off-by: Chris Wilson
---
tests/Makefile.sources | 1 +
tests/i915/gem_ctx_clone.c | 460 +
tests/meson.build | 1 +
3 files changed, 462 insertions(+)
create mode 100644 t
v2: Test each shared context is its own timeline and allows request
reordering between shared contexts.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Michal Wajdeczko
---
lib/i915/gem_context.c| 68 +++
lib/i915/gem_context.h| 13 +
Check that the extended create interface accepts setparam.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_create.c | 225 ++--
1 file changed, 213 insertions(+), 12 deletions(-)
diff --git a/tests/i915/gem_ctx_create.c b/tests/i915/gem_ctx_create.c
index a664
A stray git add from my test boxen -- we were being careful enough to
preserve priority and ordering to match the implicit policies.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/ge
Exercise the in-kernel load balancer checking that we can distribute
batches across the set of ctx->engines to avoid load.
Signed-off-by: Chris Wilson
---
tests/Makefile.am |1 +
tests/Makefile.sources |1 +
tests/i915/gem_exec_balancer.c | 1050 +
To exercise the new I915_CONTEXT_PARAM_ENGINES and interactions with
gem_execbuf().
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Reviewed-by: Andi Shyti
---
tests/Makefile.sources | 1 +
tests/i915/gem_ctx_engines.c | 517 +++
tests/mes
Exercise basic creation and swapping between new address spaces.
v2: Check isolation that the same vm_id on different fd are indeed
different VM.
v3: Cross-over check with CREATE_EXT_SETPARAM
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
lib/Makefile.sources
On 08/05/2019 09:06, Chris Wilson wrote:
Allow the user to direct which physical engines of the virtual engine
they wish to execute one, as sometimes it is necessary to override the
load balancing algorithm.
v2: Only kick the virtual engines on context-out if required
Signed-off-by: Chris Wils
On 08/05/2019 09:06, Chris Wilson wrote:
To simplify the next patch, update bump_priority and schedule to accept
the internal i915_sched_ndoe directly and not expect a request pointer.
add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7)
Function old new
On 08/05/2019 09:06, Chris Wilson wrote:
In all likelihood, the priority and node are already in the CPU cache
and by checking them first, we can avoid having to chase the
*request->hwsp for the current breadcrumb.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915
On 08/05/2019 09:06, Chris Wilson wrote:
Currently there is an underlying assumption that i915_request_unsubmit()
is synchronous wrt the GPU -- that is the request is no longer in flight
as we remove it. In the near future that may change, and this may upset
our signaling as we can process an in
On 08/05/2019 09:06, Chris Wilson wrote:
Having hid the partially exposed new ABI from the PR, put it back again
for completion of context recovery. A significant part of context
recovery is the ability to reuse as much of the old context as is
feasible (to avoid expensive reconstruction). The b
On 08/05/2019 09:06, Chris Wilson wrote:
The SINGLE_TIMELINE flag can be used to create a context such that all
engine instances within that context share a common timeline. This can
be useful for mixing operations between real and virtual engines, or
when using a composite context for a single
== Series Details ==
Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs
URL : https://patchwork.freedesktop.org/series/60404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6063 -> Patchwork_12983
Summary
---
**SU
On 08/05/2019 09:06, Chris Wilson wrote:
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the
On 08/05/2019 09:06, Chris Wilson wrote:
Allow the user to specify a local engine index (as opposed to
class:index) that they can use to refer to a preset engine inside the
ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES.
This will be useful for setting SSEU parameters on vi
Op 25-04-2019 om 18:29 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> On HSW the pipe A panel fitter lives inside the display power well,
> and the input MUX for the EDP transcoder needs to be configured
> appropriately to route the data through the power well as needed.
> Changing the MUX setti
== Series Details ==
Series: series starting with [01/40] drm/i915/hangcheck: Replace
hangcheck.seqno with RING_HEAD
URL : https://patchwork.freedesktop.org/series/60403/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
67b421614964 drm/i915/hangcheck: Replace hangcheck.seqno wit
== Series Details ==
Series: series starting with [01/40] drm/i915/hangcheck: Replace
hangcheck.seqno with RING_HEAD
URL : https://patchwork.freedesktop.org/series/60403/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/hangcheck: Replace hangc
Quoting Tvrtko Ursulin (2019-05-08 11:29:34)
>
> On 08/05/2019 09:06, Chris Wilson wrote:
> > +static int live_virtual_engine(void *arg)
> > +{
> > + struct drm_i915_private *i915 = arg;
> > + struct intel_engine_cs *siblings[MAX_ENGINE_INSTANCE + 1];
> > + struct intel_engine_cs *engi
== Series Details ==
Series: series starting with [01/40] drm/i915/hangcheck: Replace
hangcheck.seqno with RING_HEAD
URL : https://patchwork.freedesktop.org/series/60403/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6063 -> Patchwork_12984
===
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load.
Currently there is an underlying assumption that i915_request_unsubmit()
is synchronous wrt the GPU -- that is the request is no longer in flight
as we remove it. In the near future that may change, and this may upset
our signaling as we can process an interrupt for that request while it
is no long
Move the duplicated code within dma-fence.c into the header for wider
reuse.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile| 10 +-
drivers/dma-buf/dma-fence-trace.c | 28 +++
drivers/dma-buf/dma-fence.c | 32 +--
drivers/gpu/drm/i915/gt
On 08/05/2019 12:23, Chris Wilson wrote:
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the
On 08/05/2019 12:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-08 11:29:34)
On 08/05/2019 09:06, Chris Wilson wrote:
+static int live_virtual_engine(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct intel_engine_cs *siblings[MAX_ENGINE_INSTANCE + 1];
+ struct
== Series Details ==
Series: series starting with [01/40] drm/i915/hangcheck: Replace
hangcheck.seqno with RING_HEAD (rev4)
URL : https://patchwork.freedesktop.org/series/60403/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e7ad7ff7e483 drm/i915/hangcheck: Replace hangcheck.se
== Series Details ==
Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs
URL : https://patchwork.freedesktop.org/series/60404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6063_full -> Patchwork_12983_full
Summary
-
On 08/05/2019 12:24, Chris Wilson wrote:
Currently there is an underlying assumption that i915_request_unsubmit()
is synchronous wrt the GPU -- that is the request is no longer in flight
as we remove it. In the near future that may change, and this may upset
our signaling as we can process an in
If the HW fail to ack a change in forcewake status, the machine is as
good as dead -- it may recover, but in reality it missed the mmio
updates and is now in a very inconsistent state. If it happens, we can't
trust the CI results (or at least the fails may be genuine but due to
the HW being dead an
On 08/05/2019 12:25, Chris Wilson wrote:
Move the duplicated code within dma-fence.c into the header for wider
reuse.
For this one I am not sure whether to go with static inlines or
EXPORT_SYMBOL the helpers.
Also you'll need to mention that in the same patch you are optimized the
whole-li
== Series Details ==
Series: series starting with [01/40] drm/i915/hangcheck: Replace
hangcheck.seqno with RING_HEAD (rev4)
URL : https://patchwork.freedesktop.org/series/60403/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/hangcheck: Replac
1 - 100 of 192 matches
Mail list logo
