On 18/02/20 06:47, Chris Wilson wrote:
I915_EXEC_BLT only exists on gen6+
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1256
Signed-off-by: Chris Wilson
Acked-by: Antonio Argenziano
---
lib/intel_batchbuffer.c | 23 ---
1 file changed, 8 insertions
On 18/02/20 09:42, Chris Wilson wrote:
Check that reads are serialised after a write, and that a subsequent
write is after all reads.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
Cc: Sravan Kumar Nedunoori
---
tests/i915/gem_exec_schedule.c | 73
void libapi(int i915)
+{
+ struct i915_context_param_engines engines = {};
Is there a case for invalid engines as well?
Acked-by: Antonio Argenziano
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param
On 14/02/20 11:40, Chris Wilson wrote:
Setup a context with no engines, and make sure we reject all execution
attempts.
Signed-off-by: Chris Wilson
Reviewed-by: Antonio Argenziano
---
tests/i915/gem_ctx_engines.c | 45
1 file changed, 45
ng(fd, e2->flags))
+ (fd < 0) ||
Patch LGTM, Chris do you have any issues merging this before someone
implements some tests for the infrastructure?
Acked-by: Antonio Argenziano
+ gem_has_ring(fd, e2->flags)) {
+
On 06/02/20 02:06, Chris Wilson wrote:
The current implementation of the test only maps the arguments in gtt,
but we have similar problems arising from any of our own custom
pagefault handlers.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
Cc: Dixit Ashutosh
For the series
On 03/02/20 13:45, Chris Wilson wrote:
The gtt/readonly tests are nothing to do with execution and engines;
they are strictly checking the copy-from-user of the ioctl arguments.
Drop the silly per-engine tests.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
LGTM.
Reviewed-by
On 03/02/20 14:18, Chris Wilson wrote:
Quoting Antonio Argenziano (2020-02-03 22:15:26)
On 03/02/20 13:45, Chris Wilson wrote:
@@ -121,30 +43,29 @@ igt_main
igt_fixture {
fd = drm_open_driver(DRIVER_INTEL);
- igt_require_gem(fd
On 03/02/20 13:45, Chris Wilson wrote:
The gtt/readonly tests are nothing to do with execution and engines;
they are strictly checking the copy-from-user of the ioctl arguments.
Drop the silly per-engine tests.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
---
tests/i915
On 29/01/20 14:24, Chris Wilson wrote:
Do a pass over gem_exec_reloc where we inject lots of SIGINTs.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
LGTM.
Reviewed-by: Antonio Argenziano
---
tests/i915/gem_exec_reloc.c | 13 +
1 file changed, 9 insertions(+), 4
On 22/01/20 08:26, Janusz Krzysztofik wrote:
Working with a userptr GEM object backed by any type of mapping to
another GEM object, not only GTT mapping currently examined bu the
test, may cause a currently unavoidable lockdep splat inside the i915
driver. Then, such operations are expected t
On 12/11/19 10:21, Chris Wilson wrote:
Quoting Antonio Argenziano (2019-11-12 18:17:41)
On 12/11/19 07:47, Chris Wilson wrote:
If a test is only targeting the GGTT API and its corner cases, it can
only run if we have a mappable aperture.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
On 12/11/19 07:47, Chris Wilson wrote:
If a test is only targeting the GGTT API and its corner cases, it can
only run if we have a mappable aperture.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
---
lib/i915/gem_mman.c | 19 +++
lib/i915/gem_mman.h
can be discarded.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
LGTM.
Acked-by: Antonio Argenziano
---
overlay/Makefile.am | 2 -
overlay/gpu-top.c | 167 +---
overlay/igfx.c | 264
all bases.
Still, fixes the test so:
Reviewed-by: Antonio Argenziano
Antonio
else
mmio_base = 0x1a000;
break;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
On 29/05/19 16:27, Lucas De Marchi wrote:
Now that core options are set to 500 and above, start from the lowest
values without causing problems with conflicts. This also rename the
constants to follow the names from the core.
Signed-off-by: Lucas De Marchi
Acked-by: Antonio Argenziano
individual test.
While at it, fix the coding style to use tab rather than space.
Signed-off-by: Lucas De Marchi
Acked-by: Antonio Argenziano
---
lib/igt_core.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 9c86d664
Check madvise versus more memory mappings.
Suggested-by: Chris Wilson
Signed-off-by: Antonio Argenziano
---
tests/i915/gem_madvise.c | 115 ++-
1 file changed, 76 insertions(+), 39 deletions(-)
diff --git a/tests/i915/gem_madvise.c b/tests/i915
On 21/03/19 11:02, Anusha wrote:
From: Anusha Srivatsa
Add CML IDS and additional CNL ID.
Please add the kernel commits to be consistent with the previous updates.
Acked-by: Antonio Argenziano
v2: Copy header from kernel (Jose)
- Change commit message (Lucas)
Cc: José Roberto de
On 07/03/19 13:59, Chris Wilson wrote:
Quoting Antonio Argenziano (2019-03-07 19:11:15)
Some devices will not expose a mappable aperture anymore so we need to
return an appropriate value in that case.
Signed-off-by: Antonio Argenziano
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Cc: Chris
Extend the API to return the mappable aperture size directly in the
I915_GEM_GET_APERTURE IOCTL.
Signed-off-by: Antonio Argenziano
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
include/uapi/drm/i915_drm.h | 5 +
2 files
Some devices will not expose a mappable aperture anymore so we need to
return an appropriate value in that case.
Signed-off-by: Antonio Argenziano
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1
it didn't apply to context-less
platforms as it would fail here.
I think it still makes sense to test you get banned on context 0 so,
Reviwed-by: Antonio Argenziano
-
- /* And check it actually works! */
- execbuf.rsvd1 = ctx;
-
On 21/02/19 08:11, Chris Wilson wrote:
Quoting Antonio Argenziano (2019-02-21 16:08:04)
On 21/02/19 02:19, Chris Wilson wrote:
To control hang detection, we manipulate the i915.reset module
parameter. However, to be nice we should SKIP if we cannot modify the
parameter as opposed to
On 21/02/19 02:19, Chris Wilson wrote:
If we tell the machine to reset but they are disallowed, we will leave
the system in a wedged state, preventing the majority of subsequent
tests.
Signed-off-by: Chris Wilson
LGTM.
Reviewed-by: Antonio Argenziano
---
tests/i915/i915_hangman.c | 7
On 21/02/19 02:19, Chris Wilson wrote:
To control hang detection, we manipulate the i915.reset module
parameter. However, to be nice we should SKIP if we cannot modify the
parameter as opposed to outright FAILing.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108891
Signed-off-by: C
from the GPU.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
LGTM.
Reviewed-by: Antonio Argenziano
Antonio
---
tests/i915/gem_exec_schedule.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index
kernel unable to fulfil
typo -^
our request (and those naughty batches continue to disrupt testing).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Petri Latvala
Re-enabling reset sounds good.
Acked-by: Antonio Argenziano
On 19/02/19 09:11, Chris Wilson wrote:
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
v2: And send an execbuf down the new context.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Antonio Argenziano
Reviewed-by: Antonio Argenziano
On 17/02/19 06:35, Chris Wilson wrote:
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_eio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/i915/gem_eio
On 17/02/19 06:35, Chris Wilson wrote:
Lock down the new uABI that DRM_IOCTL_I915_GEM_CONTEXT_CREATE returns
-EIO when wedged.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
LGTM.
Reviewed-by: Antonio Argenziano
---
tests/i915/gem_eio.c | 14 ++
1 file changed, 14
On 29/01/19 10:01, Chris Wilson wrote:
Quoting Antonio Argenziano (2019-01-29 17:55:45)
On 29/01/19 01:55, Chris Wilson wrote:
Present the latency results in nanoseconds not RCS cycles.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 38
s[n]);
}
+
+ igt_fixture
+ igt_stop_hang_detector(no.fd);
This doesn't take an fd... incoming changes to the lib?
Still makes sense, with fix,
Reviewed-by: Antonio Argenziano
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.o
ed" otherwise.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109481
Signed-off-by: Chris Wilson
LGTM.
Reviwed-by: Antonio Argenziano
---
tests/i915/gem_exec_capture.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_capt
On 27/01/19 04:49, Chris Wilson wrote:
Check that we are allowed to hang/reset the GPU before we actually do so
for the first time.
Signed-off-by: Chris Wilson
---
tests/i915/gem_eio.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_eio.c b/tests/
On 29/01/19 01:55, Chris Wilson wrote:
Present the latency results in nanoseconds not RCS cycles.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_latency.c | 38 +++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_exec_laten
On 27/01/19 05:13, Chris Wilson wrote:
Check the GPU (using GEM) is up an operational before submitting
commands.
Always a good idea.
Reviewed-by: Antonio Argenziano
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/pm_rpm.c
On 16/01/19 09:42, Antonio Argenziano wrote:
On 16/01/19 08:15, Tvrtko Ursulin wrote:
On 11/01/2019 21:28, John Harrison wrote:
On 1/11/2019 09:31, Antonio Argenziano wrote:
On 11/01/19 00:22, Tvrtko Ursulin wrote:
On 11/01/2019 00:47, Antonio Argenziano wrote:
On 07/01/19 08:58
On 16/01/19 08:15, Tvrtko Ursulin wrote:
On 11/01/2019 21:28, John Harrison wrote:
On 1/11/2019 09:31, Antonio Argenziano wrote:
On 11/01/19 00:22, Tvrtko Ursulin wrote:
On 11/01/2019 00:47, Antonio Argenziano wrote:
On 07/01/19 08:58, Tvrtko Ursulin wrote:
On 07/01/2019 13:57, Chris
On 11/01/19 00:22, Tvrtko Ursulin wrote:
On 11/01/2019 00:47, Antonio Argenziano wrote:
On 07/01/19 08:58, Tvrtko Ursulin wrote:
On 07/01/2019 13:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 13:43:29)
On 07/01/2019 11:58, Tvrtko Ursulin wrote:
[snip]
Note about future
On 07/01/19 08:58, Tvrtko Ursulin wrote:
On 07/01/2019 13:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-07 13:43:29)
On 07/01/2019 11:58, Tvrtko Ursulin wrote:
[snip]
Note about future interaction with preemption: Preemption could happen
in a command sequence prior to watchdog
.
Signed-off-by: Chris Wilson
LGTM.
Acked-by: Antonio Argenziano
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 10/01/19 13:29, Chris Wilson wrote:
Quoting Chris Wilson (2019-01-10 21:27:54)
Quoting Antonio Argenziano (2019-01-10 21:24:56)
On 07/01/19 04:41, Chris Wilson wrote:
On Skylake, BB_OFFSET seems to be unstable. Since this is an
offset into the batch at the time of CS execution, it
On 07/01/19 04:41, Chris Wilson wrote:
On Skylake, BB_OFFSET seems to be unstable. Since this is an
offset into the batch at the time of CS execution, it should be actively
written to as we read from the register so allow it a qword of
discrepancy (since the CS should be reading in qwords). Thi
context created!
References: https://bugs.freedesktop.org/show_bug.cgi?id=109049
Signed-off-by: Chris Wilson
LGTM.
Reviwed-by: Antonio Argenziano
---
tests/amdgpu/amd_prime.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/amdgpu/amd_prime.c b/tests/amdgpu
On 05/12/18 02:48, Chris Wilson wrote:
To try and help debug situations where the driver has leaked a runtime
reference before executing the pm_rpm tests, show the contents of
i915_runtime_pm_status at startup, which will include all currently held
wakerefs.
LGTM.
Reviewed-by: Antonio
On 02/10/18 01:30, Joonas Lahtinen wrote:
Quoting Antonio Argenziano (2018-10-01 22:53:46)
Fair enough.
Acked-by: Antonio Argenziano
for the series.
Please, read the following chapters (they're applicable for the patch
tag meanings in IGT, too):
https://www.kernel.org/doc/html/
On 01/10/18 12:43, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-10-01 19:36:24)
On 28/09/18 03:19, Chris Wilson wrote:
If the driver doesn't support the getfb iface (e.g. because KMS has been
disabled), the ioctls will fail with ENOTSUP. This is expected, so skip
the te
On 28/09/18 03:19, Chris Wilson wrote:
If the driver doesn't support the getfb iface (e.g. because KMS has been
disabled), the ioctls will fail with ENOTSUP. This is expected, so skip
the test as nothing useful can be learnt.
Signed-off-by: Chris Wilson
---
tests/kms_getfb.c | 40 ++
degrades into the existing mechanism.
Signed-off-by: Chris Wilson
LGTM. Just, if I have to be really picky, the comment for
quiescent_gpu() says it is installed as an exit handler.
Reviewed-by: Antonio Argenziano
---
lib/drmtest.c | 25 +++--
lib/igt_debugfs.h
On 17/08/18 10:49, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-17 18:29:09)
On 15/08/18 02:25, Chris Wilson wrote:
Fixes: d8e78990aa2b ("igt/pm_rpm: Test reaquisition of runtime-pm after module
reload")
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 2 ++
On 15/08/18 13:59, Chris Wilson wrote:
Keep the drm_fd owned by pm_rpm as we need to relinquish all ownership
of the device in order to unload the module.
Signed-off-by: Chris Wilson
LGTM.
Reviewed-by: Antonio Argenziano
---
tests/pm_rpm.c | 5 -
1 file changed, 4 insertions
On 15/08/18 02:25, Chris Wilson wrote:
Fixes: d8e78990aa2b ("igt/pm_rpm: Test reaquisition of runtime-pm after module
reload")
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index 65489bcdb..a4f9f783e 100
On 10/08/18 04:01, Chris Wilson wrote:
More variants on stress waits to serve the dual purpose of investigating
different aspects of the latency (this time while also serving
execlists interrupts) while also checking that we never miss the wakeup.
Signed-off-by: Chris Wilson
---
tests/gem_s
On 16/08/18 00:08, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-16 00:59:30)
On 15/08/18 10:24, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 18:20:10)
On 15/08/18 03:26, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 00:50:43)
On 10/08/18 04:01
On 15/08/18 10:24, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 18:20:10)
On 15/08/18 03:26, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 00:50:43)
On 10/08/18 04:01, Chris Wilson wrote:
This exercises a special case that may be of interest, waiting for a
On 15/08/18 03:26, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-15 00:50:43)
On 10/08/18 04:01, Chris Wilson wrote:
This exercises a special case that may be of interest, waiting for a
context that may be preempted in order to reduce the wait.
Signed-off-by: Chris Wilson
On 10/08/18 04:01, Chris Wilson wrote:
This exercises a special case that may be of interest, waiting for a
context that may be preempted in order to reduce the wait.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 146 +++
1 file changed, 146
On 14/08/18 11:27, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-10 19:11:02)
On 10/08/18 10:51, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-10 18:41:22)
How does the test fail if the sync goes wrong? Hang detector on the
queued batch?
We have a hang detector for
On 10/08/18 10:51, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-10 18:41:22)
On 10/08/18 04:01, Chris Wilson wrote:
Normally we wait on the last request, but that overlooks any
difficulties in waiting on a request while the next is being qeued.
/s/qeued/queued
Check those
On 10/08/18 04:01, Chris Wilson wrote:
Normally we wait on the last request, but that overlooks any
difficulties in waiting on a request while the next is being qeued.
/s/qeued/queued
Check those.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 72
On 17/07/18 05:43, Chris Wilson wrote:
Quoting Chris Wilson (2018-07-13 18:57:41)
This was always a placeholder for GVT stakeholders to provide some
better tests. 2 years later and none have been put forward so stop
wasting CI's time running a placeholder.
Bugzilla: https://bugs.freedesktop.o
On 13/07/18 03:06, Chris Wilson wrote:
From: Antonio Argenziano
An hanging batch is nothing more than a spinning batch that never gets
stopped, so re-use the routines implemented in dummyload.c.
v2: Let caller decide spin loop size
v3: Only use loose loops for hangs (Chris)
v4: No requires
er of 5us, which is often larger
than the target latency.
Signed-off-by: Chris Wilson
Reviewed-by: Antonio Argenziano
---
lib/igt_dummyload.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index d32b421c6..b090b8004 1
On 15/06/18 11:56, Chris Wilson wrote:
As we hang ctx0 quite frequently, it needs to be harden against being
banned.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
For some reason I thought we had more hang stress tests.
Reviewed-by: Antonio Argenziano
---
tests/gem_eio.c | 2 +-
1
On 06/06/18 10:42, Chris Wilson wrote:
The current method of checking for a failed module load is flawed, as we
only report the error on probing it is not being reported back by
modprobe. So we have to dig inside the module_parameters while the
module is still loaded to discover the error.
v2:
On 30/05/18 12:52, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-05-30 18:30:36)
On 30/05/18 03:33, Chris Wilson wrote:
After hitting the SIGINT from execbuf, wait until the next timer signal
before trying again. This aligns the start of the ioctl to the timer,
hopefully maximising
On 30/05/18 03:33, Chris Wilson wrote:
Check twice for the signal interrupting the execbuf, because the real
world is messy.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106695
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
LGTM.
Reviewed-by: Antonio Argenziano
On 30/05/18 03:33, Chris Wilson wrote:
After hitting the SIGINT from execbuf, wait until the next timer signal
before trying again. This aligns the start of the ioctl to the timer,
hopefully maximising the amount of time we have for processing before
the next signal -- trying to prevent the cas
On 30/05/18 03:33, Chris Wilson wrote:
As we measure the ring size, we never expect to find we can not submit
no batches at all. Assert against the unexpected.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
---
lib/i915/gem_ring.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
; flushing it to idle in the
process!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
LGTM.
Reviewed-by: Antonio Argenziano
---
tests/perf_pmu.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 590e6526b..9af192dd8
spend.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106640
Signed-off-by: Chris Wilson
Cc: Tomi Sarvela
LGTM:
Reviewed-by: Antonio Argenziano
---
lib/igt_core.c | 34 --
lib/igt_core.h | 1 +
tests/drv_suspend.c
On 17/05/18 02:56, Chris Wilson wrote:
If the blitter is not available, we cannot use it as a source for dirty
rectangles. We shall have to rely on the other engines to create GPU
dirty instead.
v2: Try using lots of subgroup+fixtures
Signed-off-by: Chris Wilson
TEST_MODE_ITER_BEG
places. Also,
we have a gem_has_blt() function which is slightly different. Which is
making things quite confusing for me... I wish I had a better name but I
think we should add at least a comment to differentiate the two.
With that:
Reviewed-by: Antonio Argenziano
Thanks,
Antonio
+
On 17/05/18 09:52, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-05-17 17:29:26)
On 17/05/18 08:37, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-05-17 16:08:14)
On 17/05/18 01:23, Chris Wilson wrote:
Confirm we have the available HW before asserting it succeeds.
Signed
On 17/05/18 08:37, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-05-17 16:08:14)
On 17/05/18 01:23, Chris Wilson wrote:
Confirm we have the available HW before asserting it succeeds.
Signed-off-by: Chris Wilson
---
tests/gem_cpu_reloc.c | 1 +
1 file changed, 1 insertion
On 17/05/18 01:23, Chris Wilson wrote:
Confirm we have the available HW before asserting it succeeds.
Signed-off-by: Chris Wilson
---
tests/gem_cpu_reloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/gem_cpu_reloc.c b/tests/gem_cpu_reloc.c
index 882c312d4..e3bbcd239 100644
--
On 14/05/18 08:02, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-05-14 15:51:04)
On 12/05/18 02:03, Chris Wilson wrote:
If we trigger "too many" resets, the context and even the file, will be
banend and subsequent execbufs should fail with -EIO.
Signed-off-by: Chris Wils
On 12/05/18 02:03, Chris Wilson wrote:
If we trigger "too many" resets, the context and even the file, will be
banend and subsequent execbufs should fail with -EIO.
Signed-off-by: Chris Wilson
Does this replace gem_reset_stats@test_ban?
Thanks,
Antonio
_
On 23/04/18 08:51, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-04-23 16:37:17)
On 23/04/18 06:43, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other
On 23/04/18 06:43, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
Signed-off-by: Chris Wilson
C
On 13/04/18 08:59, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-04-13 16:54:27)
On 13/04/18 07:14, Chris Wilson wrote:
Set up a unpreemptible spinner such that the only way we can inject a
high priority request onto the GPU is by resetting the spinner. The test
fails if we trigger
On 13/04/18 07:14, Chris Wilson wrote:
Set up a unpreemptible spinner such that the only way we can inject a
high priority request onto the GPU is by resetting the spinner. The test
fails if we trigger hangcheck rather than the fast timeout mechanism.
Signed-off-by: Chris Wilson
---
lib/i91
On 12/04/18 01:43, Chris Wilson wrote:
Modesetting requires DRM_MASTER privileges, so use
drm_open_driver_master() to assert that we do acquire them.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105997
Signed-off-by: Chris Wilson
Acked-by: Antonio Argenziano
On 04/04/18 02:58, Tvrtko Ursulin wrote:
On 03/04/2018 19:34, Antonio Argenziano wrote:
On 03/04/18 11:24, Antonio Argenziano wrote:
On 03/04/18 04:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Reset and unwedge stress testing is supposed to trigger wedging or
resets
at incovenient
On 03/04/18 11:24, Antonio Argenziano wrote:
On 03/04/18 04:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Reset and unwedge stress testing is supposed to trigger wedging or resets
at incovenient times and then re-use the context so either the context or
driver tracking might get confused
On 03/04/18 04:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Reset and unwedge stress testing is supposed to trigger wedging or resets
at incovenient times and then re-use the context so either the context or
driver tracking might get confused and break.
v2:
* Renamed for more sensible na
On 22/03/18 11:14, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-03-22 17:32:46)
On 22/03/18 05:42, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-22 12:36:58)
On 22/03/2018 11:39, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-22 11:17:11)
trigger_reset(fd
On 22/03/18 05:42, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-22 12:36:58)
On 22/03/2018 11:39, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-03-22 11:17:11)
trigger_reset(fd);
+
+ /* HACK for CI */
+ igt_assert(igt_nsec_elapsed(&ts) < 5e9);
igt_seconds_
On 16/03/18 15:14, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-03-16 22:11:11)
On 13/03/18 05:31, Chris Wilson wrote:
Execute the same batch on each engine and check that the composite fence
across all engines completes only after the batch is completed on every
engine.
Signed
all = -1;
+ for_each_engine(fd, engine) {
for_each_physical_engines to avoid submitting twice to the same engine.
Other than that it LGTM.
Reviewed-by: Antonio Argenziano
+ int fence, new;
+
+ execbuf.flags = engine | LOCAL_EXEC_FENCE_OUT;
+ execbuf.rsvd2 =
son
Cc: Mika Kuoppala
LGTM.
Acked-by: Antonio Argenziano
---
tests/gem_eio.c | 108
1 file changed, 108 insertions(+)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
after each invalid request
v4: Check the frequencies reported by the kernel across the entire
range.
v5: Rewrite sandwich to create a sandwich between multiple concurrent
engines.
Signed-off-by: Chris Wilson
Cc: Praveen Paneri
Cc: Sagar A Kamble
Cc: Antonio Argenziano
LGTM.
Reviewed-by: Antonio
On 08/03/18 17:03, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-03-09 00:45:42)
On 08/03/18 09:13, Chris Wilson wrote:
Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.
v2: Split single/continuous
: Antonio Argenziano
---
tests/Makefile.am | 1 +
tests/Makefile.sources | 1 +
tests/gem_ctx_freq.c | 604 +
tests/meson.build | 1 +
4 files changed, 607 insertions(+)
create mode 100644 tests/gem_ctx_freq.c
+static void
On 07/03/18 17:18, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-03-08 00:55:47)
On 07/03/18 14:49, Chris Wilson wrote:
+static void single(int fd, const struct intel_execution_engine *e)
+{
+ const unsigned int engine = e->exec_id | e->flags;
+ uint32
On 07/03/18 14:49, Chris Wilson wrote:
Exercise some new API that allows applications to request that
individual contexts are executed within a desired frequency range.
Signed-off-by: Chris Wilson
---
tests/Makefile.am | 2 +-
tests/Makefile.sources | 1 +
tests/gem_ctx_freq.c
ssert(found);
Test changes look fine to me, failures on CI seems to be caused by the
test not waiting for reset to happen only before we would have not
caught it.
Reviwed-by: Antonio Argenziano
}
static void test_error_state_capture(unsigned ring_id,
___
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
Reviewed-by: Antonio Argenziano
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 28/02/18 23:51, Chris Wilson wrote:
Just a small variant to apply a continuous context-switch load to all
engines.
v2: Adapt to for_each_physical_engine() and sane gem_context_create()
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
LGTM.
Reviewed-by: Antonio Argenziano
1 - 100 of 171 matches
Mail list logo