From: Antonio Argenziano <antonio.argenziano@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, igt-dev@lists.freedesktop.org
Cc: Matthew Auld <matthew.auld@intel.com>
Subject: Re: [igt-dev] [RFT v4 4/6] igt/i915: Require GTT mapping to be available when needed.
Date: Wed, 27 Mar 2019 14:05:52 -0700 [thread overview]
Message-ID: <a015d2f0-ed94-7fd9-5f54-8841cbd4a882@intel.com> (raw)
In-Reply-To: <155355700301.15930.1926732769716588493@skylake-alporthouse-com>
On 25/03/19 16:36, Chris Wilson wrote:
> Quoting Antonio Argenziano (2019-03-25 23:20:41)
>> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
>> index 47f6b92b..2e4c0335 100644
>> --- a/lib/igt_dummyload.c
>> +++ b/lib/igt_dummyload.c
>> @@ -117,9 +117,11 @@ emit_recursive_batch(igt_spin_t *spin,
>> obj[BATCH].handle = gem_create(fd, BATCH_SIZE);
>> batch = __gem_mmap__wc(fd, obj[BATCH].handle,
>> 0, BATCH_SIZE, PROT_WRITE);
>> - if (!batch)
>> + if (!batch) {
>> + gem_require_mmap_gtt(fd);
>> batch = gem_mmap__gtt(fd, obj[BATCH].handle,
>> BATCH_SIZE, PROT_WRITE);
>
> batch = __gem_mmap__gtt();
> igt_require(batch) ?
>
> Possibly not as informative as gem_require_mmap_gtt() So ~o~
>
>> diff --git a/tests/i915/gem_concurrent_all.c b/tests/i915/gem_concurrent_all.c
>> index f719b0a1..e4fc1426 100644
>> --- a/tests/i915/gem_concurrent_all.c
>> +++ b/tests/i915/gem_concurrent_all.c
>> @@ -1422,6 +1422,7 @@ static void cpu_require(void)
>>
>> static void gtt_require(void)
>> {
>> + gem_require_mmap_gtt(fd);
>> }
>
> Needs the combinatorial explosion to exercise accessing via mmap-offset.
> If you only update one stress test, update this one.
Don't we get the mmap-offset coverage by default in the wc test cases or
do you mean to use the mmap_offset IOCTL to mmap GTT?
>
>> static void bcs_require(void)
>> diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
>> index 3afa5c15..bf1b50d5 100644
>> --- a/tests/i915/gem_ctx_sseu.c
>> +++ b/tests/i915/gem_ctx_sseu.c
>> @@ -528,8 +528,10 @@ igt_main
>> igt_subtest("invalid-sseu")
>> test_invalid_sseu(fd);
>>
>> - igt_subtest("ggtt-args")
>> + igt_subtest("ggtt-args") {
>> + gem_require_mmap_gtt(fd);
>> test_ggtt_args(fd);
>> + }
>>
>> igt_subtest("engines")
>> test_engines(fd);
>
>> diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
>> index 837f60a6..bb4eec31 100644
>> --- a/tests/i915/gem_exec_reloc.c
>> +++ b/tests/i915/gem_exec_reloc.c
>> @@ -115,6 +115,9 @@ static void from_mmap(int fd, uint64_t size, enum mode mode)
>> */
>> intel_require_memory(2, size, CHECK_RAM);
>>
>> + if ((mode & ~RO) == GTT)
>> + gem_require_mmap_gtt(fd);
>> +
>
> We need to stick arguments into mmap-offset buffers. Same is true for
> several of the "do we survive userspace being nasty with __user pointers"
> tests.
>
>> diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
>> index a9383000..15c8440f 100644
>> --- a/tests/i915/gem_exec_schedule.c
>> +++ b/tests/i915/gem_exec_schedule.c
>> @@ -1236,6 +1236,7 @@ igt_main
>> igt_subtest_f("independent-%s", e->name) {
>> igt_require(gem_ring_has_physical_engine(fd, e->exec_id | e->flags));
>> igt_require(gem_can_store_dword(fd, e->exec_id | e->flags));
>> + gem_require_mmap_gtt(fd);
>> independent(fd, e->exec_id | e->flags);
>> }
>> }
>> @@ -1328,8 +1329,10 @@ igt_main
>> igt_subtest_f("wide-%s", e->name)
>> wide(fd, e->exec_id | e->flags);
>>
>> - igt_subtest_f("reorder-wide-%s", e->name)
>> + igt_subtest_f("reorder-wide-%s", e->name) {
>> + gem_require_mmap_gtt(fd);
>> reorder_wide(fd, e->exec_id | e->flags);
>> + }
>>
>> igt_subtest_f("smoketest-%s", e->name)
>> smoketest(fd, e->exec_id | e->flags, 5);
>
> Hmm. I would rather the basic scheduling tests remained functioning.
Didn't we have a convincing argument against using wc + sync?
Antonio
>
>> diff --git a/tests/i915/gem_largeobject.c b/tests/i915/gem_largeobject.c
>> index 518396fa..a2d47edc 100644
>> --- a/tests/i915/gem_largeobject.c
>> +++ b/tests/i915/gem_largeobject.c
>> @@ -84,6 +84,8 @@ igt_simple_main
>>
>> fd = drm_open_driver(DRIVER_INTEL);
>>
>> + gem_require_mmap_gtt(fd);
>
> Ok, not mmap-offset specific in future, but one of those fun challenges.
>
>> diff --git a/tests/i915/gem_madvise.c b/tests/i915/gem_madvise.c
>> index 729a4d33..f4226a84 100644
>> --- a/tests/i915/gem_madvise.c
>> +++ b/tests/i915/gem_madvise.c
>> @@ -61,6 +61,8 @@ dontneed_before_mmap(void)
>> uint32_t handle;
>> char *ptr;
>>
>> + gem_require_mmap_gtt(fd);
>
> Needs mmap-offset integration.
>
>> diff --git a/tests/i915/gem_mmap_offset_exhaustion.c b/tests/i915/gem_mmap_offset_exhaustion.c
>> index 8c8e3fa2..86464231 100644
>> --- a/tests/i915/gem_mmap_offset_exhaustion.c
>> +++ b/tests/i915/gem_mmap_offset_exhaustion.c
>> @@ -82,6 +82,8 @@ igt_simple_main
>>
>> fd = drm_open_driver(DRIVER_INTEL);
>>
>> + gem_require_mmap_gtt(fd);
>
> Some might say this became a more important test. Not sure if the test
> itself is the best strategy (vs the selftest approach), but it
> definitely shouldn't just be skipped for mmap-offset.
>
>> diff --git a/tests/i915/gem_render_copy.c b/tests/i915/gem_render_copy.c
>> index 8d62a0f4..5757c547 100644
>> --- a/tests/i915/gem_render_copy.c
>> +++ b/tests/i915/gem_render_copy.c
>> @@ -572,6 +572,8 @@ static void test(data_t *data, uint32_t tiling, uint64_t ccs_modifier)
>> int opt_dump_aub = igt_aub_dump_enabled();
>> int num_src = ARRAY_SIZE(src);
>>
>> + gem_require_mmap_gtt(data->drm_fd);
>
> We should make sure gem_render_copy remains available for debugging the
> rendercopy routines, I doubt they are going away.
>
>> diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
>> index 8f8ddf43..9962e539 100644
>> --- a/tests/i915/gem_userptr_blits.c
>> +++ b/tests/i915/gem_userptr_blits.c
>> @@ -554,6 +554,8 @@ static int test_invalid_gtt_mapping(int fd)
>> uint32_t handle;
>> char *gtt, *map;
>>
>> + gem_require_mmap_gtt(fd);
>
> userptr-blits needs mmap-offset enhancements. Principally, if we can
> mmap(MAP_FIXED) over top of an active userptr, we need to resolve that
> amicably.
> -Chris
>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-03-27 21:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 23:20 [igt-dev] [RFT v4 1/6] lib/i915/gem_mman: Remove static variables Antonio Argenziano
2019-03-25 23:20 ` [igt-dev] [RFT v4 2/6] lib/i915: Add mmap_offset support Antonio Argenziano
2019-03-25 23:20 ` [igt-dev] [RFT v4 3/6] igt/lib: Add wrapper to check if gtt mapping is available Antonio Argenziano
2019-04-16 13:25 ` Katarzyna Dec
2019-04-16 13:28 ` Chris Wilson
2019-04-16 16:43 ` Antonio Argenziano
2019-03-25 23:20 ` [igt-dev] [RFT v4 4/6] igt/i915: Require GTT mapping to be available when needed Antonio Argenziano
2019-03-25 23:36 ` Chris Wilson
2019-03-27 21:05 ` Antonio Argenziano [this message]
2019-03-27 21:19 ` Chris Wilson
2019-04-11 18:13 ` Antonio Argenziano
2019-04-11 20:07 ` Chris Wilson
2019-04-11 21:27 ` Antonio Argenziano
2019-03-27 21:24 ` Chris Wilson
2019-04-05 18:00 ` Antonio Argenziano
2019-04-05 18:04 ` Chris Wilson
2019-04-11 18:13 ` Antonio Argenziano
2019-04-11 20:08 ` Chris Wilson
2019-04-16 14:38 ` Katarzyna Dec
2019-03-25 23:20 ` [igt-dev] [RFT v4 5/6] Coherency tests that need to be using WC + sync Antonio Argenziano
2019-04-16 14:43 ` Katarzyna Dec
2019-03-25 23:20 ` [igt-dev] [RFT v4 6/6] igt/lib: If mappable aperture is missing return 0 size Antonio Argenziano
2019-04-17 9:55 ` Katarzyna Dec
2019-03-26 9:39 ` [igt-dev] ✗ Fi.CI.BAT: failure for series starting with [RFT,v4,1/6] lib/i915/gem_mman: Remove static variables Patchwork
2019-04-16 13:27 ` [igt-dev] [RFT v4 1/6] " Katarzyna Dec
2019-04-16 15:29 ` Antonio Argenziano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a015d2f0-ed94-7fd9-5f54-8841cbd4a882@intel.com \
--to=antonio.argenziano@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=igt-dev@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox