On Wed 22-05-19 06:06:31, Tetsuo Handa wrote:
[...]
> Since OOM notifier will be called after shrinkers are attempted,
> can i915 move from OOM notifier to shrinker?
That would be indeed preferable. OOM notifier is an API from hell.
--
Michal Hocko
SUSE Labs
_
== Series Details ==
Series: drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit
inorder to pass Link Layer compliance test number 400.3.1.15 (rev2)
URL : https://patchwork.freedesktop.org/series/60880/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6113_full -> P
Hi Lionel,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20190521]
[cannot apply to v5.2-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60931/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6115 -> Patchwork_13066
=
On Tue, May 21, 2019 at 04:24:58PM +0300, Ville Syrjälä wrote:
> On Mon, May 20, 2019 at 04:25:41PM -0700, Khaled Almahallawy wrote:
> > According to DP 1.4 standard, if the source supports four pre-emphasis
> > levels, then the source shall set the bit MAX_PRE-EMPHASIS_REACHED = 1 only
> > when
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60931/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Restore control o
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60931/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a7f0011a8006 drm/i915: Restore control over ppgtt for
Quoting Matthew Auld (2019-05-21 21:42:35)
> +static void clear_pages_signal_irq_worker(struct irq_work *work)
> +{
> + struct clear_pages_work *w = container_of(work, typeof(*w), irq_work);
> +
> + dma_fence_signal(&w->dma);
> + dma_fence_put(&w->dma);
> +}
> +
> +static void cle
Hi Joonas,
On Tue, 21 May 2019 16:04:16 +0300 Joonas Lahtinen
wrote:
>
> We also have an incoming patch where the Fixes: line has a comment in
> it. Does your tooling account for this when checking the Fixes: line?
I will make sure mine does.
--
Cheers,
Stephen Rothwell
pgpcXXON36fiK.pgp
De
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60930/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13065
===
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
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.
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
Reviewed-by: Tvrtko
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
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
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
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
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
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
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
On 2019/05/21 23:44, Daniel Vetter wrote:
OOM notifiers should not depend on any locks or sleepable conditionals.
If some lock directly or indirectly depended on __GFP_DIRECT_RECLAIM,
it will deadlock. Thus, despite blocking API, this should effectively be
non-blocking. All OOM
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60930/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/gtt: grab wakeref in gen6_alloc_
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/gtt: grab wakeref in
gen6_alloc_va_range
URL : https://patchwork.freedesktop.org/series/60930/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c2a5e301596f drm/i915/gtt: grab wakeref in gen6_alloc_va_range
dd9e0
On Fri, May 17, 2019 at 09:02:46AM -, Patchwork wrote:
> == Series Details ==
>
> Series: C: Revert "net/sch_generic: Shut up noise"
> URL : https://patchwork.freedesktop.org/series/60758/
> State : success
Discussed with Martin on irc, he's ok with us dropping this one. There's
still a cib
The plan is to use the blitter engine for async object clearing when
using local memory, but before we can move the worker to get_pages() we
have to first tame some more of our struct_mutex usage. With this in
mind we should be able to upstream the object clearing as some
selftests, which should se
Some steps in gen6_alloc_va_range require the HW to be awake, so ideally
we should be grabbing the wakeref ourselves and not relying on the
caller already holding it for us.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c
On Fri, 2019-05-17 at 09:17 -0700, Rodrigo Vivi wrote:
> On Thu, May 16, 2019 at 03:49:19PM +, Summers, Stuart wrote:
> > On Thu, 2019-05-16 at 18:42 +0300, Jani Nikula wrote:
> > > On Thu, 16 May 2019, "Summers, Stuart"
> > > wrote:
> > > > On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote
Hi Jani,
On Mon, Apr 29, 2019 at 03:29:36PM +0300, Jani Nikula wrote:
> It used to be handy that we only had a couple of headers, but over time
> intel_drv.h has become unwieldy. Extract declarations to a separate
> header file corresponding to the implementation module, clarifying the
> modularit
== Series Details ==
Series: series starting with [v5,1/2] drm/i915: Make sandybridge_pcode_read()
deal with the second data register
URL : https://patchwork.freedesktop.org/series/60921/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13064
==
== Series Details ==
Series: series starting with [v5,1/2] drm/i915: Make sandybridge_pcode_read()
deal with the second data register
URL : https://patchwork.freedesktop.org/series/60921/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make s
== Series Details ==
Series: series starting with [v5,1/2] drm/i915: Make sandybridge_pcode_read()
deal with the second data register
URL : https://patchwork.freedesktop.org/series/60921/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e58657ffae31 drm/i915: Make sandybridge_pco
== Series Details ==
Series: series starting with [1/4] mm: Check if mmu notifier callbacks are
allowed to fail (rev2)
URL : https://patchwork.freedesktop.org/series/60874/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13063
=
On 21/05/2019 18:48, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 18:19:50)
On 21/05/2019 18:07, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:54)
+ if (eb->oa_config &&
+ eb->oa_config != eb->i915->perf.oa.exclusive_stream->oa_config) {
But the
== Series Details ==
Series: series starting with [1/4] mm: Check if mmu notifier callbacks are
allowed to fail (rev2)
URL : https://patchwork.freedesktop.org/series/60874/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b2f1812e79cc mm: Check if mmu notifier callbacks are allow
On 21/05/2019 18:17, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 17:50:30)
On 21/05/2019 17:36, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:52)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f263a8374273..2ad95977
== Series Details ==
Series: series starting with [v4,1/2] drm/i915/selftests: Verify context
workarounds (rev3)
URL : https://patchwork.freedesktop.org/series/60857/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13062
===
Quoting Lionel Landwerlin (2019-05-21 18:19:50)
> On 21/05/2019 18:07, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-05-21 15:08:54)
> >> + if (eb->oa_config &&
> >> + eb->oa_config !=
> >> eb->i915->perf.oa.exclusive_stream->oa_config) {
> > But the oa_config is not orde
== Series Details ==
Series: fbcon notifier begone! (rev2)
URL : https://patchwork.freedesktop.org/series/60843/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13061
Summary
---
**FAILURE**
Seriou
== Series Details ==
Series: drm/i915: Vulkan performance query support
URL : https://patchwork.freedesktop.org/series/60916/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13060
Summary
---
**FAILUR
== Series Details ==
Series: drm: Allow modeset on unregisted connectors unconditionally (rev2)
URL : https://patchwork.freedesktop.org/series/60871/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6110_full -> Patchwork_13054_full
===
== Series Details ==
Series: fbcon notifier begone! (rev2)
URL : https://patchwork.freedesktop.org/series/60843/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: dummycon: Sprinkle locking checks
Okay!
Commit: fbdev: locking check for fb_set_suspend
Oka
On 21/05/2019 18:07, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:54)
+ if (eb->oa_config &&
+ eb->oa_config != eb->i915->perf.oa.exclusive_stream->oa_config) {
But the oa_config is not ordered with respect to requests, and the
registers changed here are not c
Quoting Lionel Landwerlin (2019-05-21 17:50:30)
> On 21/05/2019 17:36, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2019-05-21 15:08:52)
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >> index f263a8374273..2ad95977f7a8 100644
> >> --- a/dr
== Series Details ==
Series: drm/i915: add i2c symlink under hdmi connector (rev2)
URL : https://patchwork.freedesktop.org/series/60866/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6110_full -> Patchwork_13053_full
Summar
== Series Details ==
Series: fbcon notifier begone! (rev2)
URL : https://patchwork.freedesktop.org/series/60843/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6712c9a81334 dummycon: Sprinkle locking checks
-:45: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal
Quoting Lionel Landwerlin (2019-05-21 15:08:54)
> + if (eb->oa_config &&
> + eb->oa_config != eb->i915->perf.oa.exclusive_stream->oa_config) {
But the oa_config is not ordered with respect to requests, and the
registers changed here are not context saved and so may be changed by a
On 21/05/2019 17:43, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:53)
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these O
On 21/05/2019 17:36, Chris Wilson wrote:
Quoting Lionel Landwerlin (2019-05-21 15:08:52)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f263a8374273..2ad95977f7a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_l
On Mon, May 06, 2019 at 04:48:01PM +0300, Jani Nikula wrote:
> The i915.alpha_support module parameter has caused some confusion along
> the way. Add new i915.force_probe parameter to specify PCI IDs of
> devices to probe, when the devices are recognized but not automatically
> probed by the driver
Quoting Lionel Landwerlin (2019-05-21 15:08:53)
> Here we introduce a mechanism by which the execbuf part of the i915
> driver will be able to request that a batch buffer containing the
> programming for a particular OA config be created.
>
> We'll execute these OA configuration buffers right befo
From: Ville Syrjälä
ICL has so many planes that it can easily exceed the maximum
effective memory bandwidth of the system. We must therefore check
that we don't exceed that limit.
The algorithm is very magic number heavy and lacks sufficient
explanation for now. We also have no sane way to query
From: Ville Syrjälä
The pcode mailbox has two data registers. So far we've only ever used
the one, but that's about to change. Expose the second data register to
the callers of sandybridge_pcode_read().
Signed-off-by: Ville Syrjälä
Reviewed-by: Clint Taylor
Reviewed-by: Radhakrishna Sripada
R
== Series Details ==
Series: drm/i915: Vulkan performance query support
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/perf: introduce a versioning of the i915-perf uapi
Okay!
Commit: drm/
== Series Details ==
Series: drm/i915: Vulkan performance query support
URL : https://patchwork.freedesktop.org/series/60916/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9577e457931d drm/i915/perf: introduce a versioning of the i915-perf uapi
3744cae4f12a drm/i915/perf: allow
Quoting Lionel Landwerlin (2019-05-21 15:08:52)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index f263a8374273..2ad95977f7a8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2085,7 +2085,7 @@ stati
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60909/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13059
=
On Tue, May 21, 2019 at 06:00:36PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 5:41 PM Jerome Glisse wrote:
> >
> > On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> > > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > > fairly easy to provoke a specifi
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60909/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Restore control o
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Restore control over ppgtt
for context creation ABI
URL : https://patchwork.freedesktop.org/series/60909/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0ef328fc3f6f drm/i915: Restore control over ppgtt for
== Series Details ==
Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev4)
URL : https://patchwork.freedesktop.org/series/60404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13058
Summary
---
On Tue, May 21, 2019 at 5:41 PM Jerome Glisse wrote:
>
> On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > fairly easy to provoke a specific notifier to be run on a specific
> > range: Just prep it, and then munm
On Thu, 2019-05-16 at 15:40 -0700, Daniele Ceraolo Spurio wrote:
>
>
> > --- a/drivers/gpu/drm/i915/gt/intel_sseu.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
> > @@ -9,16 +9,18 @@
> >
> > #include
> > #include
> > +#include
>
> AFAICS this header is not needed anymore. With it rem
== Series Details ==
Series: kernel.h: Add non_block_start/end()
URL : https://patchwork.freedesktop.org/series/60896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13057
Summary
---
**SUCCESS**
On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i
On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> This is a similar idea to the fs_reclaim fake lockdep lock. It's
> fairly easy to provoke a specific notifier to be run on a specific
> range: Just prep it, and then munmap() it.
>
> A bit harder, but still doable, is to provoke the
On Mon, May 20, 2019 at 11:39:44PM +0200, Daniel Vetter wrote:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep() cal
== Series Details ==
Series: kernel.h: Add non_block_start/end()
URL : https://patchwork.freedesktop.org/series/60896/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
945d83c6e58d kernel.h: Add non_block_start/end()
-:77: WARNING:SINGLE_STATEMENT_DO_WHILE_MACRO: Single statement
Quoting Tvrtko Ursulin (2019-05-21 14:22:18)
>
> On 21/05/2019 08:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-20 15:47:14)
> >> From: Tvrtko Ursulin
> >>
> >> gem_wsim uses the sw_fence timeline and confuses the script.
> >>
> >> v2:
> >> * Check the correct timeline as well. (C
== Series Details ==
Series: linux-next: manual merge of the drm-misc tree with Linus' tree (rev2)
URL : https://patchwork.freedesktop.org/series/60886/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6114 -> Patchwork_13056
On Mon, May 20, 2019 at 10:37:53AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.05.19 um 10:33 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.05.19 um 10:21 schrieb Daniel Vetter:
> > ...
> >> diff --git a/drivers/video/fbdev/core/fbmem.c
> >> b/drivers/video/fbdev/core/fbmem.c
> >> index fc3
== Series Details ==
Series: linux-next: manual merge of the drm-misc tree with Linus' tree (rev2)
URL : https://patchwork.freedesktop.org/series/60886/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9ade394d0944 linux-next: manual merge of the drm-misc tree with Linus' tree
-:1
On Tue, 21 May 2019, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
Just putting preempt on/of
On Tue, May 21, 2019 at 12:46:38PM +0200, Michal Hocko wrote:
> On Tue 21-05-19 12:06:11, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a n
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not al
On Tue 21-05-19 14:43:38, Cristopher Lameter wrote:
> On Tue, 21 May 2019, Daniel Vetter wrote:
>
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a non_block_sta
== Series Details ==
Series: drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit
inorder to pass Link Layer compliance test number 400.3.1.15 (rev2)
URL : https://patchwork.freedesktop.org/series/60880/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6113 -> Patchw
On Tue, May 21, 2019 at 08:24:53PM +0900, Tetsuo Handa wrote:
> On 2019/05/21 20:11, Michal Hocko wrote:
> > On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
> >> On 2019/05/21 19:51, Michal Hocko wrote:
> >>> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
> On 2019/05/21 19:06, Daniel Vetter wrot
== Series Details ==
Series: drm/i915: Fix the interpretation of MAX_PRE-EMPHASIS_REACHED bit
inorder to pass Link Layer compliance test number 400.3.1.15 (rev2)
URL : https://patchwork.freedesktop.org/series/60880/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ee90db0cb06a dr
This is unused code since
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
when fbcon was made a compile-time static dependency of fbdev. We
can't exit fbcon anymore without exiting f
Here we introduce a mechanism by which the execbuf part of the i915
driver will be able to request that a batch buffer containing the
programming for a particular OA config be created.
We'll execute these OA configuration buffers right before executing a
set of userspace commands so that a particu
Listing configurations at the moment is supported only through sysfs.
This might cause issues for applications wanting to list
configurations from a container where sysfs isn't available.
This change adds a way to query the number of configurations and their
content through the i915 query uAPI.
v
Hi all,
This small (but maybe not to everybody's taste) series enables us to
support performance queries on Vulkan. We've gone through the process
to define this as a Vulkan INTEL extension (it should appear on [1]
soonish).
We'll publish the Mesa side shortly.
Cheers,
[1] : https://github.com
We want the ability to dispatch a set of command buffer to the
hardware, each with a different OA configuration. To achieve this, we
reuse a couple of fields from the execbuf2 struct (I CAN HAZ
execbuf3?) to notify what OA configuration should be used for a batch
buffer. This requires the process m
Reporting this version will help application figure out what level of
the support the running kernel provides.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
include/uapi/drm/i915_drm.h | 20
2 files changed, 23 insertions(+)
diff --git a
We would like to make use of perf in Vulkan. The Vulkan API is much
lower level than OpenGL, with applications directly exposed to the
concept of command buffers (pretty much equivalent to our batch
buffers). In Vulkan, queries are always limited in scope to a command
buffer. In OpenGL, the lack of
Hi Tvrtko,
On Mon, May 20, 2019 at 03:47:36PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Instead of hardcoding the VCS balancing engines, discover, both with the
> new engines query, or with the legacy get_param in the fallback case, so
> class based addressing always works.
>
> v2
On 14-May-19 9:40 PM, Ville Syrjälä wrote:
On Tue, May 14, 2019 at 03:13:21PM +0530, Swati Sharma wrote:
v3: -Rebase
v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani]
-Added the default label above the correct label [Jani]
-Corrected smatch warn "variable derefe
On Mon, May 20, 2019 at 04:25:41PM -0700, Khaled Almahallawy wrote:
> According to DP 1.4 standard, if the source supports four pre-emphasis
> levels, then the source shall set the bit MAX_PRE-EMPHASIS_REACHED = 1 only
> when trasmitter programmed PRE-EMPHASIS_SET field (bits 4:3) to 11b (Level
On 21/05/2019 08:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-20 15:47:14)
From: Tvrtko Ursulin
gem_wsim uses the sw_fence timeline and confuses the script.
v2:
* Check the correct timeline as well. (Chris)
Signed-off-by: Tvrtko Ursulin
---
scripts/trace.pl | 3 +++
1 file
We also have an incoming patch where the Fixes: line has a comment in
it. Does your tooling account for this when checking the Fixes: line?
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l
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.
Quoting Stephen Rothwell (2019-05-20 15:15:38)
> Hi all,
>
> In commit
>
> 0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
> signaler")
>
> Fixes tag
>
> Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
>
> has these problem(s):
>
>
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
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
Reviewed-by: Tvrtko
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
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
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
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
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
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
1 - 100 of 136 matches
Mail list logo
