On 19/07/2021 19:30, Jason Ekstrand wrote:
If the driver was not fully loaded, we may still have globals lying
around. If we don't tear those down in i915_exit(), we'll leak a bunch
of memory slabs. This can happen two ways: use_kms = false and if we've
run mock selftests. In either case, we
On 20/07/2021 15:53, Jason Ekstrand wrote:
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
On 19/07/2021 19:30, Jason Ekstrand wrote:
If the driver was not fully loaded, we may still have globals lying
around. If we don't tear those down in i915_exit(), we'll leak a bunch
On 20/07/2021 16:05, Jason Ekstrand wrote:
Sorry... didn't reply to everything the first time
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
On 19/07/2021 19:30, Jason Ekstrand wrote:
If the driver was not fully loaded, we may still have globals lying
around. If we don&#
Now you confused me with two replies I forgot to reply to all... :))
On 20/07/2021 15:53, Jason Ekstrand wrote:
On Tue, Jul 20, 2021 at 3:25 AM Tvrtko Ursulin
wrote:
[snip]
+
static int __init i915_init(void)
{
bool use_kms = true;
int err;
+ i915_fully_loaded
always return 1
so we get the desired behavior of the driver always succeeding to load
the driver and then properly tearing down the partially loaded driver.
Signed-off-by: Jason Ekstrand
Cc: Daniel Vetter
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_pci.c | 104 --
_id id;
for_each_engine_masked(engine, gt, engine_mask, id)
- gen8_clear_engine_error_register(engine);
+ gen6_clear_engine_error_register(engine);
}
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
S0_HW 3
-#define VCS1_HW4
-#define VCS2_HW6
-#define VCS3_HW7
-#define VECS1_HW 12
/* Gen11+ HW Engine class + instance */
#define RENDER_CLASS 0
Story checks out AFAICS.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
_MMIO(0x4094)
#define GEN12_RING_FAULT_REG _MMIO(0xcec4)
#define GEN8_RING_FAULT_ENGINE_ID(x)(((x) >> 12) & 0x7)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
On 21/07/2021 00:20, Lucas De Marchi wrote:
This is only used by GRAPHICS_VER == 6 and GRAPHICS_VER == 7. All other
recent platforms do not depend on this field, so it doesn't make much
sense to keep it generic like that. Instead, just do a mapping from
engine class to HW ID in the single place
On 16/07/2021 21:17, Matthew Brost wrote:
Requests may take slightly longer with GuC submission, let's increase
the timeouts in live_requests.
Hm "slightly" ends up 5x longer here and one second feels a lot.
Out of curiosity, given this is about a simple submit of a no-op batches
in a tight
On 16/07/2021 21:17, Matthew Brost wrote:
From: John Harrison
Some testing environments and some heavier tests are slower than
What testing environments are they? It's not a simulation patch which
"escaped" by accident I am wondering. If not then it's just GuC which is
so slow, like that
On 21/07/2021 19:44, Lucas De Marchi wrote:
On Wed, Jul 21, 2021 at 10:25:59AM +0100, Tvrtko Ursulin wrote:
On 21/07/2021 00:20, Lucas De Marchi wrote:
This is only used by GRAPHICS_VER == 6 and GRAPHICS_VER == 7. All other
recent platforms do not depend on this field, so it doesn't
On 21/07/2021 19:32, Daniel Vetter wrote:
This essentially reverts
commit 84a1074920523430f9dc30ff907f4801b4820072
Author: Chris Wilson
Date: Wed Jan 24 11:36:08 2018 +
drm/i915: Shrink the GEM kmem_caches upon idling
mm/vmscan.c:do_shrink_slab() is a thing, if there's an issue w
On 22/07/2021 11:16, Daniel Vetter wrote:
On Thu, Jul 22, 2021 at 11:02:55AM +0100, Tvrtko Ursulin wrote:
On 21/07/2021 19:32, Daniel Vetter wrote:
This essentially reverts
commit 84a1074920523430f9dc30ff907f4801b4820072
Author: Chris Wilson
Date: Wed Jan 24 11:36:08 2018 +
On 16/07/2021 21:16, Matthew Brost wrote:
With GuC virtual engines the physical engine which a request executes
and completes on isn't known to the i915. Therefore we can't attach a
request to a physical engines breadcrumbs. To work around this we create
a single breadcrumbs per engine class wh
On 20/07/2021 02:59, Matthew Brost wrote:
On Tue, Jul 13, 2021 at 10:06:17AM +0100, Tvrtko Ursulin wrote:
On 24/06/2021 08:04, Matthew Brost wrote:
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
and
On 22/07/2021 14:37, Jason Ekstrand wrote:
On Thu, Jul 22, 2021 at 5:34 AM Tvrtko Ursulin
wrote:
On 22/07/2021 11:16, Daniel Vetter wrote:
On Thu, Jul 22, 2021 at 11:02:55AM +0100, Tvrtko Ursulin wrote:
On 21/07/2021 19:32, Daniel Vetter wrote:
This essentially reverts
commit
On 15/07/2021 10:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs proposing
the common specification which should enable nice common userspace tools to be
written.
For the moment I only have intel_gpu_top converted to use this
On 23/07/2021 12:23, Christian König wrote:
Am 23.07.21 um 13:21 schrieb Tvrtko Ursulin:
On 15/07/2021 10:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs
proposing
the common specification which should enable nice common
On 21/07/2021 21:17, Jason Ekstrand wrote:
On Wed, Jul 21, 2021 at 1:32 PM Daniel Vetter wrote:
This essentially reverts
commit 84a1074920523430f9dc30ff907f4801b4820072
Author: Chris Wilson
Date: Wed Jan 24 11:36:08 2018 +
drm/i915: Shrink the GEM kmem_caches upon idling
mm/vm
On 23/07/2021 20:29, Daniel Vetter wrote:
With the global kmem_cache shrink infrastructure gone there's nothing
special and we can convert them over.
I'm doing this split up into each patch because there's quite a bit of
noise with removing the static global.slab_ce to just a
slab_ce.
Cc: Jas
On 23/07/2021 17:43, Daniel Stone wrote:
Hi Tvrtko,
Thanks for typing this up!
On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin
wrote:
+Mandatory fully standardised keys
+-
+
+- drm-driver:
+
+String shall contain a fixed string uniquely identified the driver
---
*From:* Daniel Vetter
*Sent:* Friday, July 23, 2021 9:47 AM
*To:* Daniel Stone
*Cc:* Tvrtko Ursulin ; intel-gfx
; Tvrtko Ursulin
; Koenig, Christian
; dri-devel ;
Nieto, David M
*Subject:* Re: [RFC 6/8] drm: Document fdinfo format spec
On 26/07/2021 16:42, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
wrote:
On 23/07/2021 20:29, Daniel Vetter wrote:
With the global kmem_cache shrink infrastructure gone there's nothing
special and w
e the param next to all the other params which just return true.
Testcase: igt/gem_userptr_blits/probe
Signed-off-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Daniel Vette
On 26/07/2021 17:20, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 11:08 AM Tvrtko Ursulin
wrote:
On 26/07/2021 16:42, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 3:35 AM Tvrtko Ursulin
wrote:
On 23/07/2021 20:29, Daniel Vetter
On 26/07/2021 23:48, Matthew Brost wrote:
On Thu, Jul 15, 2021 at 10:36:51AM +0100, Tvrtko Ursulin wrote:
On 24/06/2021 08:05, Matthew Brost wrote:
Reset implementation for new GuC interface. This is the legacy reset
implementation which is called when the i915 owns the engine hang check
On 26/07/2021 19:17, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 11:31 AM Tvrtko Ursulin
wrote:
On 26/07/2021 17:20, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 11:08 AM Tvrtko Ursulin
wrote:
On 26/07/2021 16:42, Jason Ekstrand wrote:
On Mon, Jul 26, 2021 at 10:30 AM Jason Ekstrand
matters a lot.
Regards,
Tvrtko
Cc: Jason Ekstrand
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_module.c | 113
drivers/gpu/drm/i915/i915_pci.c| 117
From: Tvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressions reported with an enabled IOMMU
can be almost eliminated by turning them on, lets do that
-enable THP we might start seeing the failure.
Fix this by forcing I915_SHRINK_ACTIVE.
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests
failure.
Fix this by forcing I915_SHRINK_ACTIVE.
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests
From: Tvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressions reported with an enabled IOMMU
can be almost eliminated by turning them on, lets do that
On 29/07/2021 13:07, Daniel Vetter wrote:
On Thu, Jul 29, 2021 at 1:19 PM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of p
failure.
Fix this by forcing I915_SHRINK_ACTIVE.
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests
From: Tvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf
("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it
appears majority of performance regressions reported with an enabled IOMMU
can be almost eliminated by turning them on, lets just do
On 30/07/2021 01:13, John Harrison wrote:
On 7/28/2021 17:34, Matthew Brost wrote:
If an engine associated with a context does not have a heartbeat, ban it
immediately. This is needed for GuC submission as a idle pulse doesn't
kick the context off the hardware where it then can check for a
hea
On 30/07/2021 19:13, John Harrison wrote:
On 7/30/2021 02:49, Tvrtko Ursulin wrote:
On 30/07/2021 01:13, John Harrison wrote:
On 7/28/2021 17:34, Matthew Brost wrote:
If an engine associated with a context does not have a heartbeat,
ban it
immediately. This is needed for GuC submission as
supported.
Signed-off-by: Tvrtko Ursulin
Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Reported-by: Eero T Tamminen
---
drivers/gpu/drm/i915/i915_pmu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace likely doesn't care about stolen.
- mem->type is only set
ion types, or flags of some sort, but I haven't looked
at the callers to have a good idea what would work best.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
return ERR_PTR(-EINVAL);
stolen = kzalloc(sizeof(*stolen), GFP_KERNEL);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 10 ++
1 file changed, 6 in
ory */
+ i915_gem_object_put(obj);
+ return ERR_PTR(-EREMOTE);
I am a fan of rich errnos and this one feels appropriately descriptive,
but please get an ack from Daniel or so.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
+ }
+
fb = in
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.
Cc: Matthew Auld
Cc: CQ Tang
Suggested-by: Michal Wajdeczko
Signed-off-by: Ve
On 12/04/2021 10:05, Matthew Auld wrote:
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant for much older hw, therefore we can drop the
has_aperture check since it should always be
On 12/04/2021 10:05, Matthew Auld wrote:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
drivers/gpu/drm/i915/gt/intel_gtt.c | 27 +--
driv
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata Sandeep Dhanalakota
Determine the
On 15/04/2021 16:59, Matthew Auld wrote:
Add a note about the two-step process.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20, Matthew Auld wrote:
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
On 12/04/2021
On 16/04/2021 16:04, Matthew Auld wrote:
On 14/04/2021 16:01, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2
On 16/04/2021 15:25, Matthew Auld wrote:
On 14/04/2021 16:33, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant
On 19/04/2021 15:37, Matthew Auld wrote:
On 19/04/2021 15:07, Tvrtko Ursulin wrote:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld wrote:
On Thu, 15 Apr 2021 at 09:21, Tvrtko Ursulin
wrote:
On 14/04/2021 17:20
nt types of stolen so such things shouldn't be needed
anymore.
v3:
- split stolen lmem vs smem ops(Tvrtko)
- add shortcut for stolen region in i915(Tvrtko)
- sanity check dsm base vs bar size(Xinyun)
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
Cc
On 20/04/2021 14:18, Matthew Auld wrote:
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
v2: move setting I915_BO_ALLOC_CONTIGUOUS into create_stolen
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
On 19/04/2021 16:19, Jason Ekstrand wrote:
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
On 16/04/2021 17:38, Jason Ekstrand wrote:
On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming
On 20/04/2021 18:00, Jason Ekstrand wrote:
On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
wrote:
On 19/04/2021 16:19, Jason Ekstrand wrote:
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
On 16/04/2021 17:38, Jason Ekstrand wrote:
On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld
On 21/04/2021 14:54, Jason Ekstrand wrote:
On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
wrote:
On 20/04/2021 18:00, Jason Ekstrand wrote:
On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
wrote:
On 19/04/2021 16:19, Jason Ekstrand wrote:
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld
over the way down from the
caller, but for now we don't have a use for that.
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_sto
ng
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
Cc: Xinyun Liu
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 132 ++---
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 3 +-
drivers/gpu/drm/i915/i915_drv.h| 7 ++
drivers/gpu/drm/i915/i915_pci.c
On 21/04/2021 12:42, Matthew Auld wrote:
On 19/04/2021 16:01, Tvrtko Ursulin wrote:
On 19/04/2021 15:37, Matthew Auld wrote:
On 19/04/2021 15:07, Tvrtko Ursulin wrote:
On 19/04/2021 12:30, Matthew Auld wrote:
On 15/04/2021 12:05, Tvrtko Ursulin wrote:
On 15/04/2021 10:23, Matthew Auld
On 21/04/2021 18:17, Jason Ekstrand wrote:
On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
wrote:
On 21/04/2021 14:54, Jason Ekstrand wrote:
On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
wrote:
On 20/04/2021 18:00, Jason Ekstrand wrote:
On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
From: Tvrtko Ursulin
When we ban a context, for instance when userspace marked itself as non-
persistent and has exited, we apply a 1ms grace period after which any
belonging workload still on the GPU (did not preempt) will be forcibly
terminated (using engine reset).
For some workloads period
On 26/04/2021 09:57, Matthew Auld wrote:
On Wed, 21 Apr 2021 at 20:13, Matthew Auld
wrote:
On Wed, 21 Apr 2021 at 16:41, Tvrtko Ursulin
wrote:
On 21/04/2021 12:42, Matthew Auld wrote:
On 19/04/2021 16:01, Tvrtko Ursulin wrote:
On 19/04/2021 15:37, Matthew Auld wrote:
On 19/04/2021
there is address space
pressure in there and is that a concern if we do not?
Regards,
Tvrtko
v2: (Thomas) Rebase on dma_resv and obj->mm.lock removal.
Signed-off-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
.../drm/i915/gem/selftests/i915_gem_context.c |
On 26/04/2021 11:18, Matthew Auld wrote:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
v2: use i915_coherent_map_type()
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
drivers/gpu/drm
On 26/04/2021 17:18, Matthew Auld wrote:
On 26/04/2021 16:20, Tvrtko Ursulin wrote:
On 26/04/2021 11:18, Matthew Auld wrote:
We need to general our accessor for the page directories and tables from
Generalise?
using the simple kmap_atomic to support local memory, and this setup
must be
shouldn't care too much about 32b.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Signed-off-by: Matthew Auld
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
.../drm/i915/gem/selftests/i915_gem_context.c | 11 +
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 11 ++---
drivers/gp
On 27/04/2021 09:54, Matthew Auld wrote:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
v2: use i915_coherent_map_type()
v3: improve the shared dma-resv object comment
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i9
On 28/04/2021 11:16, Daniel Vetter wrote:
On Fri, Apr 23, 2021 at 05:31:19PM -0500, Jason Ekstrand wrote:
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 7
On 28/04/2021 15:02, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko Ursulin wrote:
On 28/04/2021 11:16, Daniel Vetter wrote:
On Fri, Apr 23, 2021 at 05:31:19PM -0500, Jason Ekstrand wrote:
There's no sense in allowing userspace to create more engines than i
On 23/04/2021 23:31, Jason Ekstrand wrote:
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justi
On 23/04/2021 23:31, Jason Ekstrand wrote:
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set. This doesn't actually result in
On 23/04/2021 23:31, Jason Ekstrand wrote:
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. This doesn't fix anything but does simplify
the code a bit.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 43 +
her ways. If a client really wants a shared timeline, they can
use a syncobj and set it as an in and out fence on every submit.
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
As mentioned before I have no major problem with removing unused uapi
apart from disagreeing on when to do it.
On 28/04/2021 18:09, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
wrote:
On 28/04/2021 15:02, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko Ursulin wrote:
On 28/04/2021 11:16, Daniel Vetter wrote:
On Fri, Apr 23, 2021 at 05:31:19PM -0500
On 28/04/2021 18:24, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
wrote:
On 23/04/2021 23:31, Jason Ekstrand wrote:
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. This doesn't fix anything but does simplif
On 28/04/2021 18:26, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 10:49 AM Tvrtko Ursulin
wrote:
On 23/04/2021 23:31, Jason Ekstrand wrote:
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
eithe
From: Tvrtko Ursulin
__i915_active_call annotation is required on the retire callback to ensure
correct function alignment.
Signed-off-by: Tvrtko Ursulin
Fixes: a21ce8ad12d2 ("drm/i915/overlay: Switch to using i915_active tracking")
Cc: Chris Wilson
Cc: Matthew Auld
---
drivers/gp
From: Tvrtko Ursulin
__i915_active_call annotation is required on the retire callback to ensure
correct function alignment.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c| 2 +-
2 files changed
From: Tvrtko Ursulin
Some cleanups and improvements to checks being done when building workaround
lists. First five patches are small cleanups while the last one contains the
actual story of what gets improved.
Test-with: 20210429084130.850426-1-tvrtko.ursu...@linux.intel.com
Tvrtko Ursulin (6
From: Tvrtko Ursulin
In order to stop conflating the validation via readback with the
workaround mask I need to expose the read mask separately so
gem_workarounds IGT can continue operating correctly.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file
From: Tvrtko Ursulin
We distinguish masked registers from other workarounds by the mask (clr)
being zero for the former.
To avoid callers of the low-level wa_add having to know that, and be
passing this zero explicitly, add a wa_masked_add low-level helper
which embeds this knowledge.
Signed
From: Tvrtko Ursulin
Add a new helper wa_write_no_verify for Wa_1604278689:icl,ehl which is
a write only register. This allows the mask to correctly reflect what
bits the workaround writes versus which bits it will verify during read-
back. In turn this will allow more safety checks to be added
From: Tvrtko Ursulin
In current code we check that a workaround is not completely
overwriting the existing one, but for instance partial conflict in some
bits would get missed, as would problems involving masked registers,
courtesy of the mask (wa->clr) being forced to zero for such regist
From: Tvrtko Ursulin
Same workaround was listed two times - once under the Gen7 block and once
under the Haswell section.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
Instead of "open coding" WaEnableFloatBlendOptimization:icl via
wa_write_clr_set, which should be for non-masked workarounds, add a new
helper wa_masked_en_no_verify and use it.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarou
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In doing so we apply a very strict 1ms limit in which the left over job
has to preempt before we issues an engine
On 29/04/2021 13:24, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 04:51:19PM +0100, Tvrtko Ursulin wrote:
On 23/04/2021 23:31, Jason Ekstrand wrote:
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to
On 29/04/2021 17:31, Ville Syrjälä wrote:
On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
__i915_active_call annotation is required on the retire callback to ensure
correct function alignment.
Signed-off-by: Tvrtko Ursulin
Fixes: a21ce8ad12d2 ("drm
On 29/04/2021 18:31, Ville Syrjälä wrote:
On Thu, Apr 29, 2021 at 07:31:43PM +0300, Ville Syrjälä wrote:
On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
__i915_active_call annotation is required on the retire callback to ensure
correct function alignment
On 29/04/2021 15:54, Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
wrote:
On 28/04/2021 18:24, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
wrote:
On 23/04/2021 23:31, Jason Ekstrand wrote:
Instead of handling it like a context param
On 29/04/2021 20:16, Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 3:01 AM Tvrtko Ursulin
wrote:
On 28/04/2021 18:09, Jason Ekstrand wrote:
On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
wrote:
On 28/04/2021 15:02, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko
On 30/04/2021 07:53, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:
On Thu, Apr 29, 202
On 30/04/2021 13:30, Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:
On 30/04/2021 07:53, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:
On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 02:01:16PM
On 30/04/2021 14:07, Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 2:44 PM Tvrtko Ursulin
wrote:
On 30/04/2021 13:30, Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:
On 30/04/2021 07:53, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote
On 30/04/2021 12:48, Daniel Vetter wrote:
On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In
From: Tvrtko Ursulin
When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.
In doing so we apply a very strict 1ms limit in which the left over job
has to preempt before we issues an engine
On 27/07/2021 01:23, Matthew Brost wrote:
When using GuC submission, if a context gets banned disable scheduling
and mark all inflight requests as complete.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
1 - 100 of 2272 matches
Mail list logo
