On 04/04/2023 14:52, Matthew Brost wrote:
On Tue, Apr 04, 2023 at 10:43:03AM +0100, Tvrtko Ursulin wrote:
On 04/04/2023 01:22, Matthew Brost wrote:
Hello,
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first as
On 04/04/2023 17:00, Andi Shyti wrote:
Hi Tvrtko,
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..48f888c3da083b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6 +1
On 04/04/2023 16:39, Andi Shyti wrote:
Hi Andrzej,
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..48f888c3da083b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6
Hi,
On 03/04/2023 20:40, Joshua Ashton wrote:
Hello all!
I would like to propose a new API for allowing processes to control
the priority of GPU queues similar to RLIMIT_NICE/RLIMIT_RTPRIO.
The main reason for this is for compositors such as Gamescope and
SteamVR vrcompositor to be able to c
On 04/04/2023 01:22, Matthew Brost wrote:
Hello,
As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we
have been asked to merge our common DRM scheduler patches first as well
as develop a common solution for long running workloads with the DRM
scheduler. This RFC series is our f
__intel_gt_pm_get(engine->gt);
+
/*
* We have to serialise all potential retirement paths with our
* submission, as we don't want to underflow either the
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
On 30/03/2023 20:44, Teres Alexis, Alan Previn wrote:
On Thu, 2023-03-30 at 13:25 +0100, Tvrtko Ursulin wrote:
On 30/03/2023 01:10, Teres Alexis, Alan Previn wrote:
On Wed, 2023-03-29 at 08:43 +0100, Tvrtko Ursulin wrote:
On 28/03/2023 18:52, Rodrigo Vivi wrote:
On Tue, Mar 28, 2023 at 05
On 31/03/2023 05:18, Ira Weiny wrote:
Zhao Liu wrote:
From: Zhao Liu
The use of kmap_atomic() is being deprecated in favor of
kmap_local_page()[1], and this patch converts the calls from
kmap_atomic() to kmap_local_page().
The main difference between atomic and local mappings is that local
On 31/03/2023 03:26, Ashutosh Dixit wrote:
On ATSM the PL1 limit is disabled at power up. The previous uapi assumed
that the PL1 limit is always enabled and therefore did not have a notion of
a disabled PL1 limit. This results in erroneous PL1 limit values when the
PL1 limit is disabled. For ex
On 31/03/2023 07:25, Matthew Auld wrote:
On Mon, 20 Mar 2023 at 15:14, Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
When considering whether to mark one context as stopped and another as
started we need to look at whether the previous and new _contexts_ are
different and not just requests
On 31/03/2023 04:33, Ira Weiny wrote:
Zhao Liu wrote:
From: Zhao Liu
The use of kmap_atomic() is being deprecated in favor of
kmap_local_page()[1], and this patch converts the call from
kmap_atomic() to kmap_local_page().
The main difference between atomic and local mappings is that local
m
On 30/03/2023 15:35, Andrzej Hajda wrote:
From: Chris Wilson
There may be a disconnect between the GT used by the engine and the GT
used for the VM, requiring us to hold a wakeref on both while the GPU is
active with this request.
Presumably this is for MTL? "drm/i1915/mtl: ..." ?
Signed-
On 30/03/2023 01:10, Teres Alexis, Alan Previn wrote:
On Wed, 2023-03-29 at 08:43 +0100, Tvrtko Ursulin wrote:
On 28/03/2023 18:52, Rodrigo Vivi wrote:
On Tue, Mar 28, 2023 at 05:01:36PM +, Teres Alexis, Alan Previn wrote:
On Mon, 2023-03-27 at 17:15 +0100, Tvrtko Ursulin wrote
On 28/03/2023 18:19, Daniel Vetter wrote:
On Sat, Mar 25, 2023 at 11:24:56AM -0700, Rob Clark wrote:
Hi Dave and Daniel,
Here is the series for dma-fence deadline hint, without driver
specific patches, with the intent that it can be merged into drm-next
as well as -driver next trees to enable
On 29/03/2023 01:48, Umesh Nerlige Ramappa wrote:
On Tue, Mar 28, 2023 at 02:08:47PM +0100, Tvrtko Ursulin wrote:
On 28/03/2023 10:36, Min Li wrote:
Userspace can guess the id value and try to race oa_config object
creation
with config remove, resulting in a use-after-free if we
On 28/03/2023 18:52, Rodrigo Vivi wrote:
On Tue, Mar 28, 2023 at 05:01:36PM +, Teres Alexis, Alan Previn wrote:
On Mon, 2023-03-27 at 17:15 +0100, Tvrtko Ursulin wrote:
These two:
e6177ec586d1 ("drm/i915/huc: stall media submission until HuC is loaded")
b76c14c8fb2a (&qu
__u32 pad;
+ /**
+* @deadline_ns - fence deadline hint
+*
+* Deadline hint, in absolute CLOCK_MONOTONIC, to set on backing
+* fence(s) if the DRM_SYNCOBJ_WAIT_FLAGS_WAIT_DEADLINE flag is
+* set.
+*/
+ __u64 deadline_ns;
};
FWIW,
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
On 08/03/2023 15:52, Rob Clark wrote:
From: Rob Clark
This consists of simply storing the most recent deadline, and adding an
ioctl to retrieve the deadline. This can be used in conjunction with
the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various
sw_sync fences, merge them
id, oa_config->id);
+ mutex_unlock(&perf->metrics_lock);
- return oa_config->id;
+ return id;
sysfs_err:
mutex_unlock(&perf->metrics_lock);
LGTM.
Reviewed-by: Tvrtko Ursulin
Umesh or Lionel could you please double check? I can merge if confirmed okay.
Regards,
Tvrtko
On 27/03/2023 18:47, Rodrigo Vivi wrote:
+Daniel
On Mon, Mar 27, 2023 at 09:58:52AM -0700, Dixit, Ashutosh wrote:
On Sun, 26 Mar 2023 04:52:59 -0700, Rodrigo Vivi wrote:
Hi Rodrigo,
On Fri, Mar 24, 2023 at 04:31:22PM -0700, Dixit, Ashutosh wrote:
On Fri, 24 Mar 2023 11:15:02 -0700, Be
On 27/03/2023 08:07, Lionel Landwerlin wrote:
On 26/03/2023 14:18, Rodrigo Vivi wrote:
On Sat, Mar 25, 2023 at 02:19:21AM -0400, Teres Alexis, Alan Previn
wrote:
alan:snip
@@ -353,8 +367,20 @@ int intel_pxp_start(struct intel_pxp *pxp)
alan:snip
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+
On 23/03/2023 00:27, Teres Alexis, Alan Previn wrote:
On Fri, 2023-03-17 at 13:37 +0200, Tamminen, Eero T wrote:
Hi,
On 16.3.2023 10.50, Tvrtko Ursulin wrote:
[ 11.674183] i915 :00:02.0: PXP init-arb-session-15 failed due
to BIOS/SOC:0x101a:ERR_PLATFORM_CONFIG
...
Alan - is this
On 20/03/2023 17:36, Kees Cook wrote:
On Fri, Mar 17, 2023 at 12:18:01PM -0600, Gustavo A. R. Silva wrote:
Zero-length arrays as fake flexible arrays are deprecated and we are
moving towards adopting C99 flexible-array members instead.
Address the following warning found with GCC-13 and
-fstr
From: Tvrtko Ursulin
When considering whether to mark one context as stopped and another as
started we need to look at whether the previous and new _contexts_ are
different and not just requests. Otherwise the software tracked context
start time was incorrectly updated to the most recent lite
On 16/03/2023 15:48, Das, Nirmoy wrote:
On 3/16/2023 3:27 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
No need to look at the mask of present engines when we already have a
count stored ever since e2d0ff3525b9 ("drm/i915: Count engine instances
per uabi class").
Signed-off-
From: Tvrtko Ursulin
No need to look at the mask of present engines when we already have a
count stored ever since e2d0ff3525b9 ("drm/i915: Count engine instances
per uabi class").
Signed-off-by: Tvrtko Ursulin
Cc: Jonathan Cavitt
---
drivers/gpu/drm/i915/gem/i915_gem_execbuf
On 15/03/2023 09:16, Eero Tamminen wrote:
Hi,
Tested the patch with Ubuntu 22.04 desktop + Linux 6.2-rc3 (drm-tip)
kernel, on TGL-H HW.
With it, this log spam has disappeared:
[ 8691.608933] i915 :00:02.0: [drm] PXP firmware failed ar
a const * in the near future.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: Daniele Ceraolo Spurio
Cc: Alan Previn
Cc: John Harrison
Cc: Greg Kroah-Hartman
Cc: Tony Ye
Cc: Vitaly Lubart
Cc: intel-...@lists.freedesktop.org
Hi,
On 14/03/2023 15:33, Christian König wrote:
Am 14.03.23 um 15:18 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Thread group id (aka pid from userspace point of view) is a more
interesting thing to show as an owner of a DRM fd, so track and show that
instead of the thread id.
In the
On 10/03/2023 00:59, Ashutosh Dixit wrote:
The fallback to requested freq does not work for SLPC because SLPC does not
use 'struct intel_rps'. Also for SLPC requested freq can only be obtained
from a hw register after acquiring forcewake which we don't want to do for
PMU. Therefore remove fallb
*/
- val = intel_rps_read_rpstat_fw(rps);
- if (val)
- val = intel_rps_get_cagf(rps, val);
I think you can un-export this one now.
With that looks okay to me, with or without the other stuff:
Reviewed-by: Tvrtko Ursulin
Regards,
T
From: Tvrtko Ursulin
When notified by the drm core we are over our allotted time budget, i915
instance will check if any of the GPU engines it is reponsible for is
fully saturated. If it is, and the client in question is using that
engine, it will throttle it.
For now throttling is done
From: Tvrtko Ursulin
Implement the drm_cgroup_ops->active_time_us callback.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 10
drivers/gpu/drm/i915/i915_drm_client.c | 76 ++
drivers/gpu/drm/i915/i915_drm_client.h | 2 +
3 fi
From: Tvrtko Ursulin
Similar to CPU scheduling, implement a concept of weight in the drm cgroup
controller.
Uses the same range and default as the CPU controller - CGROUP_WEIGHT_MIN,
CGROUP_WEIGHT_DFL and CGROUP_WEIGHT_MAX.
Later each cgroup is assigned a time budget proportionaly based on the
From: Tvrtko Ursulin
Add a new callback via which the drm cgroup controller is notifying the
drm core that a certain process is above its allotted GPU time.
Signed-off-by: Tvrtko Ursulin
---
include/drm/drm_drv.h | 8
kernel/cgroup/drm.c | 16
2 files changed, 24
From: Tvrtko Ursulin
To reduce the number of tracking going on, especially with drivers which
will not support any sort of control from the drm cgroup controller side,
lets express the funcionality as opt-in and use the presence of
drm_cgroup_ops as activation criteria.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
To enable propagation of settings from the cgroup DRM controller to DRM
and vice-versa, we need to start tracking to which cgroups DRM clients
belong.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_file.c | 6
include/drm/drm_file.h | 6
include
From: Tvrtko Ursulin
Add a driver callback and core helper which allow querying the time spent
on GPUs for processes belonging to a group.
Signed-off-by: Tvrtko Ursulin
---
include/drm/drm_drv.h | 28
kernel/cgroup/drm.c | 20
2 files
From: Tvrtko Ursulin
Skeleton controller without any functionality.
Signed-off-by: Tvrtko Ursulin
---
include/linux/cgroup_drm.h| 9 ++
include/linux/cgroup_subsys.h | 4 +++
init/Kconfig | 7
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c
From: Tvrtko Ursulin
With the typical model where the display server opends the file descriptor
and then hands it over to the client we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protected
From: Tvrtko Ursulin
Thread group id (aka pid from userspace point of view) is a more
interesting thing to show as an owner of a DRM fd, so track and show that
instead of the thread id.
In the next patch we will make the owner updated post file descriptor
handover, which will also be tgid based
From: Tvrtko Ursulin
This series contains a proposal for a DRM scheduling cgroup controller which
implements a weight based hierarchical GPU usage budget based controller
similar in concept to some of the existing controllers.
Motivation mostly comes from my earlier proposal where I identified
On 09/03/2023 09:59, Andrzej Hajda wrote:
On 09.03.2023 10:43, Tvrtko Ursulin wrote:
On 09/03/2023 09:34, Andrzej Hajda wrote:
On 09.03.2023 10:08, Tvrtko Ursulin wrote:
On 08/03/2023 15:39, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt
On 09/03/2023 09:34, Andrzej Hajda wrote:
On 09.03.2023 10:08, Tvrtko Ursulin wrote:
On 08/03/2023 15:39, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
to prefetch memory beyond the error_capt
On 09/03/2023 03:46, Ashutosh Dixit wrote:
Expose intel_rps_read_actual_frequency_fw to read the actual freq without
taking forcewake for use by PMU. The code is refactored to use a common set
of functions across sysfs and PMU. Using common functions with sysfs in PMU
solves the issues of missi
On 08/03/2023 15:39, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
to prefetch memory beyond the error_capture, ie it tries
to read memory pointed by next PTE in GGTT.
If this PTE points to invalid addres
On 08/03/2023 05:36, Dixit, Ashutosh wrote:
On Mon, 06 Mar 2023 03:10:24 -0800, Tvrtko Ursulin wrote:
Hi Tvrtko,
On 04/03/2023 01:27, Ashutosh Dixit wrote:
SLPC does not use 'struct intel_rps'. Use UNSLICE_RATIO bits from
Would it be more accurate to say 'SLPC d
On 08/03/2023 05:36, Dixit, Ashutosh wrote:
On Mon, 06 Mar 2023 03:04:40 -0800, Tvrtko Ursulin wrote:
Hi Tvrtko,
On 04/03/2023 01:27, Ashutosh Dixit wrote:
On newer generations, the GEN12_RPSTAT1 register contains more than freq
information, e.g. see GEN12_VOLTAGE_MASK. Therefore use
From: Tvrtko Ursulin
Use the newly added dma-fence API to apply waitboost not only requests
which have been marked with I915_WAIT_PRIORITY by i915, but which may be
waited upon by others (such as for instance buffer sharing in multi-GPU
scenarios).
Signed-off-by: Tvrtko Ursulin
---
drivers
From: Tvrtko Ursulin
Use the previously added dma-fence API to mark the direct i915 waits as
explicit. This has no significant effect apart from following the new
pattern.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 3 ++-
1 file changed, 2 insertions(+), 1
From: Tvrtko Ursulin
Userspace waits coming via the drm_syncobj route have so far been
bypassing the waitboost mechanism.
Use the previously added dma-fence wait tracking API and apply the
same waitboosting logic which applies to other entry points.
This should fix the perfomance regressions
From: Tvrtko Ursulin
As signaling is enabled on the container fence we need to propagate any
external waiting status to individual fences in order to enable owning
drivers see it.
Signed-off-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence-array.c | 5 +++--
1 file changed, 3 insertions(+), 2
From: Tvrtko Ursulin
As signaling is enabled on the container fence we need to propagate any
external waiting status to individual fences in order to enable owning
drivers see it.
Signed-off-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence-chain.c | 22 --
include/linux
From: Tvrtko Ursulin
Use the previously added dma-fence tracking of explicit waiters.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_syncobj.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 9 +
include/linux/dma-fence.h | 3 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index bdba5a8e21b1..5607acdb6ccf
From: Tvrtko Ursulin
Track how many callers are explicity waiting on a fence to signal and
allow querying that via new dma_fence_wait_count() API.
This provides infrastructure on top of which generic "waitboost" concepts
can be implemented by individual drivers. Wait-boosting is an
From: Tvrtko Ursulin
Use the previously added initialization helper to ensure correct operation
of the common code.
Signed-off-by: Tvrtko Ursulin
Cc: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
From: Tvrtko Ursulin
In preparation of adding a new field to struct dma_fence_cb we will need
an initialization helper for those callers who add callbacks by open-
coding. That will ensure they initialize all the fields so common code
does not get confused by potential garbage in some fields
From: Tvrtko Ursulin
Use the previously added initialization helper to ensure correct operation
of the common code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 2 +-
drivers/gpu/drm/i915/i915_active.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
From: Tvrtko Ursulin
Unhide some i915 helpers which are used for splitting the signalled
check vs notification stages during en masse fence processing.
Signed-off-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 35 +++--
drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
In i915 we have this concept of "wait boosting" where we give a priority boost
for instance to fences which are actively waited upon from userspace. This has
it's pros and cons and can certainly be discussed at lenght. However fact is
some workloads really li
On 04/03/2023 01:27, Ashutosh Dixit wrote:
SLPC does not use 'struct intel_rps'. Use UNSLICE_RATIO bits from
Would it be more accurate to say 'SLPC does not use rps->cur_freq'
rather than it not using struct intel_rps?
Fixes: / stable ? CI chances of catching this?
GEN6_RPNSWREQ for SLPC
On 04/03/2023 01:27, Ashutosh Dixit wrote:
On newer generations, the GEN12_RPSTAT1 register contains more than freq
information, e.g. see GEN12_VOLTAGE_MASK. Therefore use only the freq bits
to decide whether to fall back to requested freq.
Could you find an appropriate Fixes: tag please? If
On 03/03/2023 14:48, Rob Clark wrote:
On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin
wrote:
On 03/03/2023 03:21, Rodrigo Vivi wrote:
On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
From: Rob Clark
missing some wording here...
v2: rebase
Signed-off-by: Rob Clark
On 03/03/2023 03:21, Rodrigo Vivi wrote:
On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
From: Rob Clark
missing some wording here...
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_request.c | 20
1 file changed, 20 insertions(+)
d
On 24/02/2023 11:00, Pekka Paalanen wrote:
On Fri, 24 Feb 2023 10:50:51 +
Tvrtko Ursulin wrote:
On 24/02/2023 10:24, Pekka Paalanen wrote:
On Fri, 24 Feb 2023 09:41:46 +
Tvrtko Ursulin wrote:
On 24/02/2023 09:26, Pekka Paalanen wrote:
On Thu, 23 Feb 2023 10:51:48 -0800
Rob
On 24/02/2023 10:24, Pekka Paalanen wrote:
On Fri, 24 Feb 2023 09:41:46 +
Tvrtko Ursulin wrote:
On 24/02/2023 09:26, Pekka Paalanen wrote:
On Thu, 23 Feb 2023 10:51:48 -0800
Rob Clark wrote:
On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen wrote:
On Wed, 22 Feb 2023 07:37:26
On 18/02/2023 21:15, Rob Clark wrote:
From: Rob Clark
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can addjust GPU frequency a
On 24/02/2023 09:26, Pekka Paalanen wrote:
On Thu, 23 Feb 2023 10:51:48 -0800
Rob Clark wrote:
On Thu, Feb 23, 2023 at 1:38 AM Pekka Paalanen wrote:
On Wed, 22 Feb 2023 07:37:26 -0800
Rob Clark wrote:
On Wed, Feb 22, 2023 at 1:49 AM Pekka Paalanen wrote:
...
On another matter, i
On 23/02/2023 18:41, Badal Nilawar wrote:
Apply Wa_14017073508 for MTL SoC die A step instead of graphics step.
To get the SoC die stepping there is no direct interface so using
revid as revid 0 aligns with SoC die A step.
Bspec: 55420
Fixes: 8f70f1ec587d ("drm/i915/mtl: Add Wa_14017073508 fo
On 22/02/2023 17:16, Rob Clark wrote:
On Wed, Feb 22, 2023 at 9:05 AM Tvrtko Ursulin
wrote:
On 22/02/2023 15:28, Christian König wrote:
Am 22.02.23 um 11:23 schrieb Tvrtko Ursulin:
On 18/02/2023 21:15, Rob Clark wrote:
From: Rob Clark
Add a way to hint to the fence signaler of an
On 22/02/2023 15:28, Christian König wrote:
Am 22.02.23 um 11:23 schrieb Tvrtko Ursulin:
On 18/02/2023 21:15, Rob Clark wrote:
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss. This is to aid
On 18/02/2023 21:15, Rob Clark wrote:
From: Rob Clark
Propagate the deadline to all the fences in the chain.
Signed-off-by: Rob Clark
Reviewed-by: Christian König for this one.
---
drivers/dma-buf/dma-fence-chain.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drive
On 18/02/2023 21:15, Rob Clark wrote:
From: Rob Clark
Add a way to hint to the fence signaler of an upcoming deadline, such as
vblank, which the fence waiter would prefer not to miss. This is to aid
the fence signaler in making power management decisions, like boosting
frequency as the deadl
On 20/02/2023 17:18, Andrea Righi wrote:
It seems that commit bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU
mask internally in UAPI format") exposed a potential out-of-bounds
access, reported by UBSAN as following on a laptop with a gen 11 i915
card:
UBSAN: array-index-out-of-bounds
On 20/02/2023 16:44, Tvrtko Ursulin wrote:
On 20/02/2023 15:52, Rob Clark wrote:
On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin
wrote:
On 17/02/2023 20:45, Rodrigo Vivi wrote:
[snip]
Yeah I agree. And as not all media use cases are the same, as are not
all compute contexts someone
On 20/02/2023 15:52, Rob Clark wrote:
On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin
wrote:
On 17/02/2023 20:45, Rodrigo Vivi wrote:
[snip]
Yeah I agree. And as not all media use cases are the same, as are not
all compute contexts someone somewhere will need to run a series of
On 20/02/2023 15:45, Rob Clark wrote:
On Mon, Feb 20, 2023 at 4:22 AM Tvrtko Ursulin
wrote:
On 17/02/2023 17:00, Rob Clark wrote:
On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin
wrote:
[snip]
adapted from your patches.. I think the basic idea of deadlines
(which includes "I wa
On 18/02/2023 21:15, Rob Clark wrote:
From: Rob Clark
Signed-off-by: Rob Clark
---
This should probably be re-written by someone who knows the i915
request/timeline stuff better, to deal with non-immediate deadlines.
But as-is I think this should be enough to handle the case where
we want s
On 18/02/2023 19:54, Rob Clark wrote:
On Thu, Feb 16, 2023 at 3:00 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Track how many callers are explicity waiting on a fence to signal and
allow querying that via new dma_fence_wait_count() API.
This provides infrastructure on top of which
On 18/02/2023 19:56, Rob Clark wrote:
On Thu, Feb 16, 2023 at 2:59 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Use the previously added dma-fence tracking of explicit waiters.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_syncobj.c | 6 +++---
1 file changed, 3 insertions
On 17/02/2023 17:00, Rob Clark wrote:
On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin
wrote:
[snip]
adapted from your patches.. I think the basic idea of deadlines
(which includes "I want it NOW" ;-)) isn't controversial, but the
original idea got caught up in some bikes
On 17/02/2023 20:45, Rodrigo Vivi wrote:
On Fri, Feb 17, 2023 at 09:00:49AM -0800, Rob Clark wrote:
On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin
wrote:
On 17/02/2023 14:55, Rob Clark wrote:
On Fri, Feb 17, 2023 at 4:56 AM Tvrtko Ursulin
wrote:
On 16/02/2023 18:19, Rodrigo Vivi
On 20/02/2023 10:01, Christian König wrote:
Am 20.02.23 um 10:55 schrieb Tvrtko Ursulin:
Hi,
On 14/02/2023 13:59, Christian König wrote:
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the
Hi,
On 14/02/2023 13:59, Christian König wrote:
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially
fers with LLC
drm/i915: Don't use BAR mappings for ring buffers with LLC
drivers/gpu/drm/i915/gt/intel_ring.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
It is doing what it laid out as the problem statement so series looks
good to me.
Acked-by: Tvrtko Ursulin
Regards,
Tvrtko
On 17/02/2023 14:55, Rob Clark wrote:
On Fri, Feb 17, 2023 at 4:56 AM Tvrtko Ursulin
wrote:
On 16/02/2023 18:19, Rodrigo Vivi wrote:
On Tue, Feb 14, 2023 at 11:14:00AM -0800, Rob Clark wrote:
On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
In i915 we have
On 16/02/2023 18:19, Rodrigo Vivi wrote:
On Tue, Feb 14, 2023 at 11:14:00AM -0800, Rob Clark wrote:
On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
In i915 we have this concept of "wait boosting" where we give a priority boost
for instance to fences
On 16/02/2023 15:41, Matt Roper wrote:
On Thu, Feb 16, 2023 at 09:21:23AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
code become a bit unsightly. Consolidate by storing the required values at
engine init time
On 14/02/2023 19:14, Rob Clark wrote:
On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
In i915 we have this concept of "wait boosting" where we give a priority boost
for instance to fences which are actively waited upon from userspace. This has
it'
From: Tvrtko Ursulin
Userspace waits coming via the drm_syncobj route have so far been
bypassing the waitboost mechanism.
Use the previously added dma-fence wait tracking API and apply the
same waitboosting logic which applies to other entry points.
This should fix the perfomance regressions
From: Tvrtko Ursulin
Use the previously added dma-fence tracking of explicit waiters.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_syncobj.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index
From: Tvrtko Ursulin
Use the newly added dma-fence API to apply waitboost not only requests
which have been marked with I915_WAIT_PRIORITY by i915, but which may be
waited upon by others (such as for instance buffer sharing in multi-GPU
scenarios).
Signed-off-by: Tvrtko Ursulin
---
drivers
From: Tvrtko Ursulin
Use the previously added dma-fence API to mark the direct i915 waits as
explicit. This has no significant effect apart from following the new
pattern.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 3 ++-
1 file changed, 2 insertions(+), 1
From: Tvrtko Ursulin
Track how many callers are explicity waiting on a fence to signal and
allow querying that via new dma_fence_wait_count() API.
This provides infrastructure on top of which generic "waitboost" concepts
can be implemented by individual drivers. Wait-boosting is an
From: Tvrtko Ursulin
In preparation of adding a new field to struct dma_fence_cb we will need
an initialization helper for those callers who add callbacks by open-
coding. That will ensure they initialize all the fields so common code
does not get confused by potential garbage in some fields
From: Tvrtko Ursulin
Use the previously added initialization helper to ensure correct operation
of the common code.
Signed-off-by: Tvrtko Ursulin
Cc: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
From: Tvrtko Ursulin
Unhide some i915 helpers which are used for splitting the signalled
check vs notification stages during en masse fence processing.
Signed-off-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 35 +++--
drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
Use the previously added initialization helper to ensure correct operation
of the common code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 2 +-
drivers/gpu/drm/i915/i915_active.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
From: Tvrtko Ursulin
In i915 we have this concept of "wait boosting" where we give a priority boost
for instance to fences which are actively waited upon from userspace. This has
it's pros and cons and can certainly be discussed at lenght. However fact is
some workloads really li
701 - 800 of 2157 matches
Mail list logo
