On 11/01/2023 22:19, Daniel Vetter wrote:
On Tue, Jan 10, 2023 at 01:14:51PM +, Tvrtko Ursulin wrote:
On 06/01/2023 18:00, Daniel Vetter wrote:
On Fri, Jan 06, 2023 at 03:53:13PM +0100, Christian König wrote:
Am 06.01.23 um 11:53 schrieb Daniel Vetter:
On Fri, Jan 06, 2023 at 11:32
On 11/01/2023 19:40, Matthew Brost wrote:
On Wed, Jan 11, 2023 at 08:50:37AM +, Tvrtko Ursulin wrote:
[snip]
This example is where it would hurt on large systems. Imagine only an even
wider media transcode card...
Second example is only a single engine class used (3d desktop
On 11/01/2023 17:52, Matthew Brost wrote:
On Wed, Jan 11, 2023 at 09:09:45AM +, Tvrtko Ursulin wrote:
[snip]
Anyway, since you are not buying any arguments on paper perhaps you are more
open towards testing. If you would adapt gem_wsim for Xe you would be able
to spawn N simulated
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
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
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
---
drivers/gpu/drm/drm_cgroup.c | 24
include/drm/drm_clients.h| 2 ++
include/drm/drm_drv.h
From: Tvrtko Ursulin
We need the ability for DRM core to inform the cgroup controller when a
client has closed a DRM file descriptor. This will allow us not needing
to keep state relating to GPU time usage by tasks sets in the cgroup
controller itself.
Signed-off-by: Tvrtko Ursulin
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
---
drivers/gpu/drm/drm_cgroup.c | 21 +
include/drm/drm_clients.h| 1 +
include
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
Entry points from the cgroup subsystem into the drm cgroup controller will
need to walk the file_priv structures associated with registered clients
and since those are not RCU protected lets add a hack for now to make this
safe.
Signed-off-by: Tvrtko Ursulin
---
drivers
From: Tvrtko Ursulin
To enable propagation of settings from the cgroup drm controller to drm we
need to start tracking which processes own which drm clients.
Implement that by tracking the struct pid pointer of the owning process in
a new XArray, pointing to a structure containing a list
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 protec
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 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given
nned = %d\n",
+ ce->guc_id.id, test_bit(CONTEXT_EXITING, >flags),
+ test_bit(CONTEXT_BANNED, >flags));
+
if (likely(intel_context_is_schedulable(ce))) {
capture_error_state(guc, ce);
guc_context_replay(ce);
Re
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state claimed a batch was (maybe)
in progress. So,
On 12/01/2023 02:53, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is
On 10/01/2023 16:07, Matt Roper wrote:
On Tue, Jan 10, 2023 at 11:35:33AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Revert to the original explicit approach and document the reasoning
behind it.
v2:
* DG2 needs to be covered too. (Matt)
v3:
* Full version check for Gen12
On 10/01/2023 19:01, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 04:50:55PM +, Tvrtko Ursulin wrote:
On 10/01/2023 15:55, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 12:19:35PM +, Tvrtko Ursulin wrote:
On 10/01/2023 11:28, Tvrtko Ursulin wrote:
On 09/01/2023 17:27, Jason
On 11/01/2023 01:13, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 04:39:00PM +, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 11:28:08AM +, Tvrtko Ursulin wrote:
On 09/01/2023 17:27, Jason Ekstrand wrote:
[snip]
>>> AFAICT it proposes to have 1:1 between *userspace
On 10/01/2023 14:08, Jason Ekstrand wrote:
On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin
mailto:tvrtko.ursu...@linux.intel.com>>
wrote:
On 09/01/2023 17:27, Jason Ekstrand wrote:
[snip]
> >>> AFAICT it proposes to have 1:1 between *
On 10/01/2023 15:55, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 12:19:35PM +, Tvrtko Ursulin wrote:
On 10/01/2023 11:28, Tvrtko Ursulin wrote:
On 09/01/2023 17:27, Jason Ekstrand wrote:
[snip]
>>> AFAICT it proposes to have 1:1 between *userspace* created
cont
On 06/01/2023 18:00, Daniel Vetter wrote:
On Fri, Jan 06, 2023 at 03:53:13PM +0100, Christian König wrote:
Am 06.01.23 um 11:53 schrieb Daniel Vetter:
On Fri, Jan 06, 2023 at 11:32:17AM +0100, Christian König wrote:
Am 05.01.23 um 13:32 schrieb Daniel Vetter:
[SNIP]
For the case of an
On 10/01/2023 11:28, Tvrtko Ursulin wrote:
On 09/01/2023 17:27, Jason Ekstrand wrote:
[snip]
>>> AFAICT it proposes to have 1:1 between *userspace* created
contexts (per
>>> context _and_ engine) and drm_sched. I am not sure avoiding
include "intel_gt_pm.h"
+#include "intel_gt_print.h"
#include "intel_gt_requests.h"
#include "intel_llc.h"
#include "intel_pm.h"
@@ -275,8 +276,7 @@ int intel_gt_resume(struct intel_gt *gt)
/* Only when the HW is re-initialised, can we
From: Tvrtko Ursulin
Revert to the original explicit approach and document the reasoning
behind it.
v2:
* DG2 needs to be covered too. (Matt)
v3:
* Full version check for Gen12 to avoid catching all future platforms.
(Matt)
v4:
* Be totally explicit on the Gen12 branch. (Andrzej
On 09/01/2023 17:27, Jason Ekstrand wrote:
[snip]
>>> AFAICT it proposes to have 1:1 between *userspace* created
contexts (per
>>> context _and_ engine) and drm_sched. I am not sure avoiding
invasive changes
>>> to the shared code is in the spirit of the overall idea
On 10/01/2023 08:23, Andrzej Hajda wrote:
On 09.01.2023 13:24, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Revert to the original explicit approach and document the reasoning
behind it.
v2:
* DG2 needs to be covered too. (Matt)
v3:
* Full version check for Gen12 to avoid catching all
On 06/01/2023 23:52, Matthew Brost wrote:
On Thu, Jan 05, 2023 at 09:43:41PM +, Matthew Brost wrote:
On Tue, Jan 03, 2023 at 01:02:15PM +, Tvrtko Ursulin wrote:
On 02/01/2023 07:30, Boris Brezillon wrote:
On Fri, 30 Dec 2022 12:55:08 +0100
Boris Brezillon wrote:
On Fri, 30 Dec
From: Tvrtko Ursulin
Revert to the original explicit approach and document the reasoning
behind it.
v2:
* DG2 needs to be covered too. (Matt)
v3:
* Full version check for Gen12 to avoid catching all future platforms.
(Matt)
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
Cc: Balasubramani
On 06/01/2023 18:57, John Harrison wrote:
On 12/6/2022 03:06, Tvrtko Ursulin wrote:
On 05/12/2022 18:44, Michal Wajdeczko wrote:
On 05.12.2022 14:16, Tvrtko Ursulin wrote:
On 02/12/2022 20:14, John Harrison wrote:
[snip]
Random meaningless (to me) message that is apparently a display
On 05/01/2023 12:32, Daniel Vetter wrote:
On Fri, Dec 02, 2022 at 10:01:01AM +0100, Christian König wrote:
Am 01.12.22 um 12:09 schrieb Tvrtko Ursulin:
On 30/11/2022 14:18, Daniel Vetter wrote:
On Wed, Nov 30, 2022 at 01:34:07PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
From: Tvrtko Ursulin
Revert to the original explicit approach and document the reasoning
behind it.
v2:
* DG2 needs to be covered too. (Matt)
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
Cc: Balasubramani Vivekanandan
Cc: Andrzej Hajda
Reviewed-by: Andrzej Hajda # v1
---
Matt, does DG1
On 05/01/2023 16:00, Tvrtko Ursulin wrote:
On 05/01/2023 15:52, Andi Shyti wrote:
Hi Rob,
On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
From: Rob Clark
gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger
On 05/01/2023 15:52, Andi Shyti wrote:
Hi Rob,
On Tue, Jan 03, 2023 at 03:49:46PM -0800, Rob Clark wrote:
From: Rob Clark
gem_context_register() makes the context visible to userspace, and which
point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.
So we need to ensure
On 05/01/2023 13:34, David Laight wrote:
From: Jani Nikula
Sent: 05 January 2023 13:28
On Thu, 05 Jan 2023, Daniel Vetter wrote:
On Mon, Dec 12, 2022 at 09:38:12AM +, David Laight wrote:
From: Andrzej Hajda
Sent: 09 December 2022 15:49
The pattern of setting variable with new value
Okay to sum it up below with some final notes..
On 04/01/2023 19:34, Matt Roper wrote:
On Wed, Jan 04, 2023 at 09:58:13AM +, Tvrtko Ursulin wrote:
On 23/12/2022 18:28, Lucas De Marchi wrote:
On Fri, Dec 23, 2022 at 09:02:35AM +, Tvrtko Ursulin wrote:
On 22/12/2022 15:55, Lucas De
On 04/01/2023 17:41, Matt Roper wrote:
On Wed, Jan 04, 2023 at 10:08:29AM +, Tvrtko Ursulin wrote:
On 03/01/2023 19:57, Matt Roper wrote:
On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
On 19.12.2022 11:13, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic
On 03/01/2023 19:57, Matt Roper wrote:
On Mon, Dec 19, 2022 at 05:10:02PM +0100, Andrzej Hajda wrote:
On 19.12.2022 11:13, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
corresponding
code become a bit unsightly
On 23/12/2022 18:28, Lucas De Marchi wrote:
On Fri, Dec 23, 2022 at 09:02:35AM +, Tvrtko Ursulin wrote:
On 22/12/2022 15:55, Lucas De Marchi wrote:
On Thu, Dec 22, 2022 at 10:27:00AM +, Tvrtko Ursulin wrote:
On 22/12/2022 08:25, Lucas De Marchi wrote:
The comments are redundant
return i915_gem_context_get(ctx);
+ return ctx;
Otherwise userspace can look up a context which hasn't had it's reference count
increased yep. I can add the Fixes: and Stable: tags while merging if no
complaints.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
}
struct i915_gem_context *
On 03/01/2023 15:39, Simon Ser wrote:
On Tuesday, January 3rd, 2023 at 16:37, Tvrtko Ursulin
wrote:
On 23/12/2022 11:26, Simon Ser wrote:
Reviewed-by: Simon Ser cont...@emersion.fr
Thanks - adding some drm-misc maintainers to consider pulling the patch in.
I can push the patches
On 23/12/2022 11:26, Simon Ser wrote:
Reviewed-by: Simon Ser
Thanks - adding some drm-misc maintainers to consider pulling the patch in.
Regards,
Tvrtko
On 02/01/2023 07:30, Boris Brezillon wrote:
On Fri, 30 Dec 2022 12:55:08 +0100
Boris Brezillon wrote:
On Fri, 30 Dec 2022 11:20:42 +0100
Boris Brezillon wrote:
Hello Matthew,
On Thu, 22 Dec 2022 14:21:11 -0800
Matthew Brost wrote:
In XE, the new Intel GPU driver, a choice has made
On 22/12/2022 22:21, Matthew Brost wrote:
Hello,
This is a submission for Xe, a new driver for Intel GPUs that supports both
integrated and discrete platforms starting with Tiger Lake (first platform with
Intel Xe Architecture). The intention of this new driver is to have a fresh base
to work
On 23/12/2022 12:18, Andi Shyti wrote:
From: Chris Wilson
On Haswell, in particular, we see an issue where resets fails because
the engine resumes from an incorrect RING_HEAD. Since the RING_HEAD
doesn't point to the remaining requests to re-run, but may instead point
into the uninitialised
From: Tvrtko Ursulin
Replace the deprecated macro with the per-device one.
Signed-off-by: Tvrtko Ursulin
Acked-by: Christian König
---
Would anyone like to r-b and merge this small cleanup?
---
drivers/gpu/drm/drm_file.c | 18 +-
drivers/gpu/drm/drm_ioc32.c | 13
On 22/12/2022 22:21, Matthew Brost wrote:
From: Maarten Lankhorst
Frontbuffer update handling should be done explicitly by using dirtyfb
calls only.
A bit terse - questions around if this breaks something, and if it does
what and why it is okay, were left hanging in the air in the
On 22/12/2022 15:55, Lucas De Marchi wrote:
On Thu, Dec 22, 2022 at 10:27:00AM +, Tvrtko Ursulin wrote:
On 22/12/2022 08:25, Lucas De Marchi wrote:
The comments are redundant to the checks being done to apply the
workarounds and very often get outdated as workarounds need to be
extended
From: Tvrtko Ursulin
This is the fix proposed by Chuansheng Liu to
close a memory leak caused by refactoring done in 786555987207
("drm/i915/gem: Store mmap_offsets in an rbtree rather than a plain list").
Original commit text from Liu was this:
>
> The below memory leak infor
On 22/12/2022 08:25, Lucas De Marchi wrote:
The comments are redundant to the checks being done to apply the
workarounds and very often get outdated as workarounds need to be
extended to new platforms or steppings. Remove them altogether with
the following matches (platforms extracted from
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 in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during
From: Tvrtko Ursulin
Revert to the original explicit approach and document the reasoning
behind it.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
Cc: Balasubramani Vivekanandan
Cc: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_gt.c | 13 -
1 file changed, 12 insertions(+), 1
From: Tvrtko Ursulin
First patch to make the platform check not catch all due current lack of
automated testing.
Second patch to consolidate the code a bit and move invariant setup at engine
init time. Don't think I want to merge this one until some test coverage can be
had.
Tvrtko Ursulin (2
On 13/12/2022 14:52, Andrzej Hajda wrote:
On 13.12.2022 13:39, 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 in the engine
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 in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during
MCR registers")
Signed-off-by: Andrzej Hajda
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_
gt;
+
+ /*
+* If full PXP feature is not available but HuC is loaded by GSC on
pre-MTL
+* such as DG2, we can skip the init of
* the full PXP session/object management and just init the tee channel.
This comment would benefit from a re-format.
*/
-
On 05/12/2022 18:44, Michal Wajdeczko wrote:
On 05.12.2022 14:16, Tvrtko Ursulin wrote:
On 02/12/2022 20:14, John Harrison wrote:
and while for dbg level messages it doesn't matter, I assume we should
be consistent for err/warn/info messages (as those will eventually show
up to the end
On 05/12/2022 16:27, Matt Roper wrote:
On Mon, Dec 05, 2022 at 12:50:40PM +, Tvrtko Ursulin wrote:
On 02/12/2022 22:49, Rodrigo Vivi wrote:
On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:
When determining whether the platform has a hardware-level steering
semaphore (i.e
On 05/12/2022 15:52, Matt Roper wrote:
On Mon, Dec 05, 2022 at 08:58:16AM +, Tvrtko Ursulin wrote:
On 28/11/2022 23:30, Matt Roper wrote:
Starting with MTL, the driver needs to not only protect the steering
control register from simultaneous software accesses, but also protect
against
On 02/12/2022 20:14, John Harrison wrote:
and while for dbg level messages it doesn't matter, I assume we should
be consistent for err/warn/info messages (as those will eventually show
up to the end user) so let maintainers decide here what is
expectation here
Could we have some examples
On 02/12/2022 22:49, Rodrigo Vivi wrote:
On Fri, Dec 02, 2022 at 02:35:28PM -0800, Matt Roper wrote:
When determining whether the platform has a hardware-level steering
semaphore (i.e., MTL and beyond), we need to use GRAPHICS_VER_FULL() to
compare the full version rather than just the major
On 28/11/2022 23:30, Matt Roper wrote:
Starting with MTL, the driver needs to not only protect the steering
control register from simultaneous software accesses, but also protect
against races with hardware/firmware agents. The hardware provides a
dedicated locking mechanism to support this
On 02/12/2022 11:11, Andi Shyti wrote:
Hi Tvrtko,
On Fri, Dec 02, 2022 at 10:20:11AM +, Tvrtko Ursulin wrote:
On 01/12/2022 20:39, Andi Shyti wrote:
From: Chris Wilson
Introduce the concept of padding the i915_vma with guard pages before
and after. The major consequence is that all
such be of no further
issue.)
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
Hi Tvrtko,
I removed your r-b in this version because I restored the original value
of the guard being aligned with the vma size alignment. Turns out that
CI
On 01/12/2022 22:03, Zanoni, Paulo R wrote:
Hi
I was given a link to https://patchwork.freedesktop.org/series/111494/
but can't seem to find it on the mailing list, so I'll reply here.
On Thu, 2022-08-25 at 08:46 +0200, Maarten Lankhorst wrote:
Frontbuffer tracking in gem is used in old
such be of no further
issue.)
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
Hi,
this the v5 changelog, the overall changelog is in the v4 cover letter:
v4 -> v5:
- remove again the GEM_BUG_ON()
- fix an oversight where the round
On 01/12/2022 11:56, Michal Wajdeczko wrote:
On 01.12.2022 01:41, John Harrison wrote:
On 11/23/2022 12:45, Michal Wajdeczko wrote:
On 23.11.2022 02:25, John Harrison wrote:
On 11/22/2022 09:54, Michal Wajdeczko wrote:
On 18.11.2022 02:58, john.c.harri...@intel.com wrote:
From: John
On 30/11/2022 14:18, Daniel Vetter wrote:
On Wed, Nov 30, 2022 at 01:34:07PM +, Tvrtko Ursulin wrote:
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
On 01/12/2022 10:45, Andi Shyti wrote:
Hi Tvrtko,
[...]
@@ -768,8 +773,17 @@ i915_vma_insert(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
GEM_BUG_ON(!IS_ALIGNED(alignment, I915_GTT_MIN_ALIGNMENT));
GEM_BUG_ON(!is_power_of_2(alignment));
+ guard = vma->guard; /*
On 30/11/2022 21:04, John Harrison wrote:
On 11/30/2022 00:30, Tvrtko Ursulin wrote:
On 29/11/2022 21:12, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never happen. But in the case when one
Engine resets or engine reset failures? Hopefully the latter
to
unnecessarily rely on third parties.
Because now we avoid adding scratch pages to the entire GGTT we
don't need this hack anymore.
Signed-off-by: Andi Shyti
Cc: Thomas Hellström
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 69 ++--
drivers
binding.
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 13 +++
drivers/gpu/drm/i915/gt/intel_ggtt.c | 25 +-
2 files changed, 14 insertions
such be of no further
issue.)
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +-
drivers/gpu/drm/i915/i915_vma.c | 40
Hi Dave, Daniel,
A few more small fixes for the release candidate week.
Fixes for confused return values when waiting on request retirement, which
can explode in the GuC backend, fix for reading on DRAM info data and a
fix to filter out impossible display pipes from the bigjoiner code.
Regards,
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 protec
From: Tvrtko Ursulin
Replace the deprecated macro with the per-device one.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_file.c | 21 +++--
drivers/gpu/drm/drm_ioc32.c | 13 +++--
drivers/gpu/drm/drm_ioctl.c | 25 +
3 files changed, 31
From: Tvrtko Ursulin
Not so long ago when I sent out my DRM cgroup controller RFC I had some pieces
in it which were tracking the real client using a specific drm_file. Christian
then suggested that should probably be extracted and improved in the DRM core
from the start, which was on his
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
On 29/11/2022 18:05, Matthew Auld wrote:
On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
wrote:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers
On 29/11/2022 21:12, john.c.harri...@intel.com wrote:
From: John Harrison
Engine resets are supposed to never happen. But in the case when one
Engine resets or engine reset failures? Hopefully the latter.
does (due to unknwon reasons that normally come down to a missing
w/a), it is
On 22/11/2022 07:01, Aravind Iddamsetty wrote:
On XE_LPM+ platforms the media engines are carved out into a separate
GT but have a common GGTMMADR address range which essentially makes
the GGTT address space to be shared between media and render GT. As a
result any updates in GGTT shall
patch first in the series, because patch 2 now
does not need to do max -> max_t on the respective line, but okay.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
such be of no further
issue.)
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 +---
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +-
drivers/gpu/drm/i915/i915_vma.c | 43
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
On 23/11/2022 16:21, Janusz Krzysztofik wrote:
On Wednesday, 23 November 2022 13:57:26 CET Tvrtko Ursulin wrote:
On 23/11/2022 09:28, Janusz Krzysztofik wrote:
Hi Tvrtko,
Thanks for your comments.
On Tuesday, 22 November 2022 11:50:38 CET Tvrtko Ursulin wrote:
On 21/11/2022 14:56
On 23/11/2022 18:54, Andi Shyti wrote:
Hi Tvrtko,
[...]
@@ -768,6 +768,9 @@ i915_vma_insert(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
GEM_BUG_ON(!IS_ALIGNED(alignment, I915_GTT_MIN_ALIGNMENT));
GEM_BUG_ON(!is_power_of_2(alignment));
+ guard = vma->guard; /*
in intel_display_power_*_domain() functions
Matthew Auld (1):
drm/i915/ttm: never purge busy objects
Sean Christopherson (2):
drm/i915/gvt: Get reference to KVM iff attachment to VM is successful
drm/i915/gvt: Unconditionally put reference to KVM when detaching vGPU
Tvrtko Ursulin (1
On 23/11/2022 09:28, Janusz Krzysztofik wrote:
Hi Tvrtko,
Thanks for your comments.
On Tuesday, 22 November 2022 11:50:38 CET Tvrtko Ursulin wrote:
On 21/11/2022 14:56, Janusz Krzysztofik wrote:
Users of intel_gt_retire_requests_timeout() expect 0 return value on
success. However, we
such be of no further
issue.)
Signed-off-by: Chris Wilson
Signed-off-by: Tejas Upadhyay
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 14
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 ++-
drivers/gpu/drm/i915/i915_vma.c | 27
ed-off-by: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 33 ++--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/dr
On 21/11/2022 14:56, Janusz Krzysztofik wrote:
Users of intel_gt_retire_requests_timeout() expect 0 return value on
success. However, we have no protection from passing back 0 potentially
returned by a call to dma_fence_wait_timeout() when it succedes right
after its timeout has expired.
Is
On 21/11/2022 23:19, Janusz Krzysztofik wrote:
Hi Andrzej,
Thanks for providing your R-b.
On Monday, 21 November 2022 18:40:51 CET Andrzej Hajda wrote:
On 21.11.2022 15:56, Janusz Krzysztofik wrote:
Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
with GuC")
On 21/11/2022 18:21, John Harrison wrote:
On 11/18/2022 02:52, Jani Nikula wrote:
On Thu, 17 Nov 2022, john.c.harri...@intel.com wrote:
From: John Harrison
When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
On 18/11/2022 17:14, Matt Roper wrote:
On Fri, Nov 18, 2022 at 11:52:49AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In 3653727560d0 ("drm/i915: Simplify internal helper function signature")
I broke the old platforms by not noticing engine workaround init does not
initializ
by default.
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Jani Nikula
Signed-off-by: Matt Roper
---
There was some recent offline discussion questioning whether we'd fully
identified the root cause of some historic CI failures, or whether it
was possible we might still have a bug
701 - 800 of 2126 matches
Mail list logo
