On Fri, May 03, 2019 at 10:08:30PM +0300, Ville Syrjala wrote:
> 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: V
On Fri, May 03, 2019 at 10:08:31PM +0300, Ville Syrjala wrote:
> 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 heav
== Series Details ==
Series: drm/i915/icl: More workaround for port F detection due to broken VBTs
URL : https://patchwork.freedesktop.org/series/60508/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6073_full -> Patchwork_13003_full
== Series Details ==
Series: Per context and per client GPU busyness tracking
URL : https://patchwork.freedesktop.org/series/60506/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6073_full -> Patchwork_13002_full
Summary
---
Quoting Tvrtko Ursulin (2019-05-10 14:23:12)
> From: Tvrtko Ursulin
>
> Adds support for per-client engine busyness stats i915 exports in sysfs
> and produces output like the below:
>
> ==
> intel-gpu-top - 935/ 935 MHz;
On Fri, May 10, 2019 at 11:28 AM Petr Mladek wrote:
>
> On Thu 2019-05-09 22:06:33, Daniel Vetter wrote:
> > console_trylock, called from within printk, can be called from pretty
> > much anywhere. Including try_to_wake_up. Note that this isn't common,
> > usually the box is in pretty bad shape at
== Series Details ==
Series: drm/i915/icl: More workaround for port F detection due to broken VBTs
URL : https://patchwork.freedesktop.org/series/60508/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6073 -> Patchwork_13003
== Series Details ==
Series: Per context and per client GPU busyness tracking
URL : https://patchwork.freedesktop.org/series/60506/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6073 -> Patchwork_13002
Summary
---
**
On Fri, May 10, 2019 at 11:15 AM Petr Mladek wrote:
> On Thu 2019-05-09 18:43:12, Daniel Vetter wrote:
> > One thing to keep in mind is that the kernel is already dying, and
> > things will come crashing down later on
>
> This is important information. I havn't seen it mentioned earlier.
I though
On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> > DRM API for generating uevent for a status changes of connector's
> > property.
> >
> > This uevent will have following details related to the status change:
> >
> > HO
Chris Wilson writes:
> 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_t
Chris Wilson writes:
> Continuing the decluttering of i915_gem.c by moving the client self
> throttling into its own file.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://l
== Series Details ==
Series: drm/i915/icl: More workaround for port F detection due to broken VBTs
URL : https://patchwork.freedesktop.org/series/60508/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
28212f668a27 drm/i915/icl: More workaround for port F detection due to broken
On Fri, May 10, 2019 at 09:15:27AM +, Ardelean, Alexandru wrote:
> On Wed, 2019-05-08 at 16:22 +0300, Alexandru Ardelean wrote:
> > On Wed, 2019-05-08 at 15:18 +0200, Greg KH wrote:
> > > On Wed, May 08, 2019 at 04:11:28PM +0300, Andy Shevchenko wrote:
> > > > On Wed, May 08, 2019 at 02:28:29PM
Quoting Mika Kuoppala (2019-05-10 15:17:12)
> > diff --git a/drivers/gpu/drm/i915/i915_utils.h
> > b/drivers/gpu/drm/i915/i915_utils.h
> > index edfc69acdaac..9911f53382a5 100644
> > --- a/drivers/gpu/drm/i915/i915_utils.h
> > +++ b/drivers/gpu/drm/i915/i915_utils.h
> > @@ -218,16 +218,6 @@ static
Chris Wilson writes:
> Continuing the decluttering of i915_gem.c by moving the object busy
> checking into its own file.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lis
Quoting Tvrtko Ursulin (2019-05-10 14:22:36)
> +static inline void
> +intel_context_in(struct intel_context *ce, bool submit)
> +{
> + struct intel_engine_cs *engine = ce->engine;
> unsigned long flags;
> + ktime_t now;
>
> if (READ_ONCE(engine->stats.enabled) == 0)
>
Chris Wilson writes:
> 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/
== Series Details ==
Series: Per context and per client GPU busyness tracking
URL : https://patchwork.freedesktop.org/series/60506/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3ae0f10d21d1 drm/i915: Move intel_engine_context_in/out into intel_lrc.c
e76b877d4273 drm/i915: Trac
Quoting Tvrtko Ursulin (2019-05-10 14:22:37)
> From: Tvrtko Ursulin
>
> Expose a list of clients with open file handles in sysfs.
>
> This will be a basis for a top-like utility showing per-client and per-
> engine GPU load.
>
> Currently we only expose each client's pid and name under opaque n
On 10/05/2019 14:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-10 14:22:39)
+static const char *uabi_class_names[] = {
+ [I915_ENGINE_CLASS_RENDER] = "0",
+ [I915_ENGINE_CLASS_COPY] = "1",
+ [I915_ENGINE_CLASS_VIDEO] = "2",
+ [COPY_ENGINE_CLASS] = "3",
I915_E
Add another ICL-Y PCIID that proved to have only 5 ports to the
corresponding PCIID list.
Meanwhile I'm trying to get a complete list of all PCIIDs with less than
6 ports and/or get a VBT fix to mark these ports non-existant, but until
then the only way is to go one-by-one.
This fixes the followi
Quoting Tvrtko Ursulin (2019-05-10 14:22:39)
> +static const char *uabi_class_names[] = {
> + [I915_ENGINE_CLASS_RENDER] = "0",
> + [I915_ENGINE_CLASS_COPY] = "1",
> + [I915_ENGINE_CLASS_VIDEO] = "2",
> + [COPY_ENGINE_CLASS] = "3",
I915_ENGINE_CLASS_VIDEO_ENHANCE?
-Chris
__
Quoting Tvrtko Ursulin (2019-05-08 13:10:54)
> From: Tvrtko Ursulin
>
> For simulating frame split workloads it is useful to express a batch which
> ends at the same time as the parallel submission on the respective bonded
> engine. For this we add support for infinite batch durations and the bat
Quoting Tvrtko Ursulin (2019-05-08 13:10:51)
> From: Tvrtko Ursulin
>
> A new workload command for enabling a load balanced context map (aka
> Virtual Engine). Example usage:
>
> B.1
>
> This turns on load balancing for context one, assuming it has already been
> configured with an engine map
Quoting Tvrtko Ursulin (2019-05-08 13:10:50)
> From: Tvrtko Ursulin
>
> Parsing an integer workload descriptor field is a common pattern which we
> can extract to a helper macro and by doing so further improve the
> readability of the main parsing loop.
>
> Signed-off-by: Tvrtko Ursulin
> ---
>
Quoting Tvrtko Ursulin (2019-05-08 13:10:53)
> From: Tvrtko Ursulin
>
> A few additional workloads useful for experimenting with scheduling.
>
> Signed-off-by: Tvrtko Ursulin
Acked-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.fr
Quoting Tvrtko Ursulin (2019-05-08 13:10:52)
> From: Tvrtko Ursulin
>
> Engine bonds are an i915 uAPI applicable to load balanced contexts with
> engine map. They allow expression rules of engine selection between two
> contexts when submissions are also tied with submit fences.
>
> Please refer
Quoting Tvrtko Ursulin (2019-05-08 13:10:49)
> From: Tvrtko Ursulin
>
> We can improve the parsing loop readability a bit more by avoiding some
> line breaks caused by explicit NULL checks.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
-Chris
_
Quoting Tvrtko Ursulin (2019-05-08 13:10:48)
> From: Tvrtko Ursulin
>
> Support new i915 uAPI for configuring contexts with engine maps.
>
> Please refer to the README file for more detailed explanation.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> +static int parse_engine_map(struct w_step *step
Quoting Tvrtko Ursulin (2019-05-08 13:10:46)
> From: Tvrtko Ursulin
>
> Add support for submit fences in a way similar to how normal input fences
> are handled. Eg:
>
> 1.RCS.500-1000.0.0
> 1.VCS1.3000.s-1.0
> 1.VCS2.3000.s-2.0
Looks like commands on a punch card. :-p
> Submit fences are
From: Tvrtko Ursulin
Adds support for per-client engine busyness stats i915 exports in sysfs
and produces output like the below:
==
intel-gpu-top - 935/ 935 MHz;0% RC6; 14.73 Watts; 1097 irqs/s
IMC reads:
Quoting Tvrtko Ursulin (2019-05-08 13:10:42)
> @@ -841,7 +846,11 @@ eb_set_engine(struct drm_i915_gem_execbuffer2 *eb,
> if (engine == VCS2 && (flags & VCS2REMAP))
> engine = BCS;
>
> - eb->flags = eb_engine_map[engine];
> + if ((flags & I915) && engine == VCS)
From: Tvrtko Ursulin
Intel_lrc.c is the only caller and so to avoid some header file ordering
issues in future patches move these two over there.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 55 -
drivers/gpu/drm/i915/gt/intel_lrc.c| 57
From: Tvrtko Ursulin
Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.
With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.
v2: Fix
From: Tvrtko Ursulin
Extension to intel_gpu_top which uses the corresponding sysfs interface proposal
to implement per client and per class engine utilization view. Example output:
==
intel-gpu-top - 935/ 935 MHz;0% RC6
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For in
From: Tvrtko Ursulin
Continuation of the old feature work, rebased to latest drm-tip and adapted to
expose data per engine class - making it compatible with the upcoming Virtual
Engine uapi.
Patch series adds core per context (intel_context) engine busyness tracking and
then also exports this da
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h
From: Tvrtko Ursulin
By default we are not collecting any per-engine and per-context
statistcs.
Add a new sysfs toggle to enable this facility:
$ echo 1 >/sys/class/drm/card0/clients/enable_stats
v2: Rebase.
v3: sysfs_attr_init.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_dr
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing o
Quoting Tvrtko Ursulin (2019-05-08 13:10:47)
> From: Tvrtko Ursulin
>
> Signed-off-by: Tvrtko Ursulin
> ---
> benchmarks/gem_wsim.c | 34 +-
> 1 file changed, 21 insertions(+), 13 deletions(-)
>
> diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
> inde
Quoting Tvrtko Ursulin (2019-05-08 13:10:42)
> From: Tvrtko Ursulin
>
> Support i915 virtual engine from gem_wsim (-b i915) and media-bench.pl
>
> Signed-off-by: Tvrtko Ursulin
> ---
> + /*
> +* Create and configure contexts.
> +*/
> + for (i = 0; i < wrk->nr_ctxs; i
Quoting Tvrtko Ursulin (2019-05-08 13:10:43)
> From: Tvrtko Ursulin
>
> We are moving towards bumping the uAPI headers more often instead of using
> too much local struct/ioctl/param definitions since the latter are more
> challenging for rebase and maintenance.
>
> Signed-off-by: Tvrtko Ursulin
Quoting Tvrtko Ursulin (2019-05-08 13:10:45)
> From: Tvrtko Ursulin
>
> A few more opportunities to compact the code by using the error logging
> helper.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
I had to double check that wsim_err() wasn't the magic cf macro.
-Chris
___
Quoting Tvrtko Ursulin (2019-05-08 13:10:44)
> From: Tvrtko Ursulin
>
> There is a repeated pattern with error handling which can be moved to a
> macro to for better readability in the command parsing loop.
>
> Signed-off-by: Tvrtko Ursulin
Bah, at the cost of including control-flow buried ins
Hi,
On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:
> DRM API for generating uevent for a status changes of connector's
> property.
>
> This uevent will have following details related to the status change:
>
> HOTPLUG=1, CONNECTOR= and PROPERTY=
>
> Need ACK from this uevent from users
Quoting Tvrtko Ursulin (2019-05-08 13:10:41)
> From: Tvrtko Ursulin
>
> Use the 'completed?' tracepoint field to detect more robustly when a
> request has been preempted and remove it from the engine database if so.
>
> Otherwise the script can hit a scenario where the same global seqno will
> b
Quoting Tvrtko Ursulin (2019-05-08 13:10:40)
> From: Tvrtko Ursulin
>
> Add virtual/queue timelines to both stdout and HTML output.
>
> A new timeline is created for each queue/virtual engine to display
> associated requests in queued and runnable states. Once requests are
> submitted to a real
Quoting Tvrtko Ursulin (2019-05-08 13:10:38)
> From: Tvrtko Ursulin
>
> After the removal of engine global seqnos and the corresponding
> intel_engine_notify tracepoints the script needs to be adjusted to cope
> with the new state of things.
>
> To keep working it switches over using the dma_fen
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: c16fd9be70faf3c49a61700efd16018dd910e390
commit: 6498bf5800a302ef69e7f4914e727893f278bb2f [4/6] drm: revocation check at
drm subsystem
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Repor
== Series Details ==
Series: RFC: console: hack up console_lock more v3 (rev4)
URL : https://patchwork.freedesktop.org/series/60467/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6073 -> Patchwork_13001
Summary
---
*
== Series Details ==
Series: RFC: console: hack up console_lock more v3 (rev4)
URL : https://patchwork.freedesktop.org/series/60467/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7e7042b1b9a6 RFC: console: hack up console_lock more v3
-:25: WARNING:COMMIT_LOG_LONG_LINE: Possibl
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: c16fd9be70faf3c49a61700efd16018dd910e390
commit: f26ae6a652f2e75a3a12ac22b7da5797978436c4 [5/6] drm/i915: SRM revocation
check for HDCP1.4 and 2.2
If you fix the issue, kindly add following tag
Reported-by: kbuild test
On Fri, May 10, 2019 at 09:13:26AM +, Ardelean, Alexandru wrote:
> On Wed, 2019-05-08 at 16:26 +0300, Alexandru Ardelean wrote:
> > On Wed, 2019-05-08 at 15:20 +0300, Dan Carpenter wrote:
> > >
> > >
> > > On Wed, May 08, 2019 at 02:28:35PM +0300, Alexandru Ardelean wrote:
> > > > -static con
== Series Details ==
Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev2)
URL : https://patchwork.freedesktop.org/series/60404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_13000_full
Summar
On Thu 2019-05-09 22:06:33, Daniel Vetter wrote:
> console_trylock, called from within printk, can be called from pretty
> much anywhere. Including try_to_wake_up. Note that this isn't common,
> usually the box is in pretty bad shape at that point already. But it
> really doesn't help when then loc
On Thu 2019-05-09 18:43:12, Daniel Vetter wrote:
> One thing to keep in mind is that the kernel is already dying, and
> things will come crashing down later on
This is important information. I havn't seen it mentioned earlier.
> (I've seen this only in dmesg
> tails capture in pstore in our CI, i
On Thu, May 09, 2019 at 03:21:57PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Align dumb buffer stride to 4k if the fb will be big enough to
> require gtt remapping.
>
> v2: Leave the stride alone for buffers that look to be for the cursor
> v3: Make it not a hack (Daniel)
>
> Cc: Da
On Thu, May 09, 2019 at 03:21:55PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Reorganize some fb stride checking code a bit to prepare for
> gtt remapping. And do a bit of s/pitch/stride/ renaming in the
> process for a bit more uniformity (apart from the whole
> fb->pitches[] thing).
On Fri, May 10, 2019 at 01:21:59PM +0800, Lu Baolu wrote:
> Forward to i915 mailing list and post the question again so people knows
> what are the key concerns.
>
> The background is that Linux community is going to collect and report
> the reserved memory ranges of an assigned device to VFIO dri
== Series Details ==
Series: drm/i915: Truly bump ready tasks ahead of busywaits
URL : https://patchwork.freedesktop.org/series/60486/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6072_full -> Patchwork_12999_full
Summary
On Fri, May 10, 2019 at 7:50 AM Sergey Senozhatsky
wrote:
>
> On (05/09/19 22:06), Daniel Vetter wrote:
> [..]
> > +/* Functions for the contended case */
> > +
> > +struct semaphore_waiter {
> > + struct list_head list;
> > + struct task_struct *task;
> > + bool up;
> > +};
> > +
> >
Quoting Chris Wilson (2019-05-09 21:51:54)
> In commit b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of
> busywaits"), I tried cutting a corner in order to not install a signal
> for each of our dependencies, and only listened to requests on which we
> were intending to busywait. The compromise t
64 matches
Mail list logo
