| Message ID | 20191023090752.23566-2-janusz.krzysztofik@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [i-g-t,1/2] tests/gem_exec_reloc: Don't filter out addresses when on PPGTT | expand |
Quoting Janusz Krzysztofik (2019-10-23 10:07:52) > From: Janusz Krzysztofik <janusz.krzysztofik@intel.com> > > The basic-range subtest assumes 4kB minimum batch size. On future > backends with possibly bigger minimum batch sizes this subtest will > fail as buffer objects may overlap. To avoid object overlapping, > offsets need to be calculated with actual minimum batch size in mind. > > Replace hardcoded constants corresponding to the assumed 4kB minimum > batch size with values calculated from a variable supposed to represent > actual batch size. For now, the variable is still initialized with the > 4kB value, suitable for backends currently supported by IGT. You could do this entirely within the reloc API, no? By probing whether a 4KiB offset is legal? -Chris
Hi Chris, On Wednesday, October 23, 2019 11:13:02 AM CEST Chris Wilson wrote: > Quoting Janusz Krzysztofik (2019-10-23 10:07:52) > > From: Janusz Krzysztofik <janusz.krzysztofik@intel.com> > > > > The basic-range subtest assumes 4kB minimum batch size. On future > > backends with possibly bigger minimum batch sizes this subtest will > > fail as buffer objects may overlap. To avoid object overlapping, > > offsets need to be calculated with actual minimum batch size in mind. > > > > Replace hardcoded constants corresponding to the assumed 4kB minimum > > batch size with values calculated from a variable supposed to represent > > actual batch size. For now, the variable is still initialized with the > > 4kB value, suitable for backends currently supported by IGT. > > You could do this entirely within the reloc API, no? By probing whether > a 4KiB offset is legal? Thanks for the hint, I'll try to take this path. Janusz > -Chris >
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c index 8f88826e..8d2f10ac 100644 --- a/tests/i915/gem_exec_reloc.c +++ b/tests/i915/gem_exec_reloc.c @@ -518,16 +518,21 @@ static void basic_range(int fd, unsigned flags) struct drm_i915_gem_execbuffer2 execbuf; uint64_t address_mask = has_64b_reloc(fd) ? ~(uint64_t)0 : ~(uint32_t)0; uint64_t gtt_size = gem_aperture_size(fd); + /* FIXME: switch to a suitable library function when available */ + uint64_t batch_size = 4096; const uint32_t bbe = MI_BATCH_BUFFER_END; igt_spin_t *spin = NULL; - int count, n; + int batch_order, count, n; igt_require(gem_has_softpin(fd)); - for (count = 12; gtt_size >> (count + 1); count++) + for (batch_order = 0; batch_size >> (batch_order + 1); batch_order++) ; - count -= 12; + for (count = batch_order; gtt_size >> (count + 1); count++) + ; + + count -= batch_order; memset(obj, 0, sizeof(obj)); memset(reloc, 0, sizeof(reloc)); @@ -535,8 +540,8 @@ static void basic_range(int fd, unsigned flags) n = 0; for (int i = 0; i <= count; i++) { - obj[n].handle = gem_create(fd, 4096); - obj[n].offset = (1ull << (i + 12)) - 4096; + obj[n].handle = gem_create(fd, batch_size); + obj[n].offset = (1ull << (i + batch_order)) - batch_size; obj[n].offset = gen8_canonical_address(obj[n].offset); obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS; if (!gem_uses_ppgtt(fd)) { @@ -556,8 +561,8 @@ static void basic_range(int fd, unsigned flags) n++; } for (int i = 1; i < count; i++) { - obj[n].handle = gem_create(fd, 4096); - obj[n].offset = 1ull << (i + 12); + obj[n].handle = gem_create(fd, batch_size); + obj[n].offset = 1ull << (i + batch_order); obj[n].offset = gen8_canonical_address(obj[n].offset); obj[n].flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS; if (!gem_uses_ppgtt(fd)) { @@ -578,7 +583,7 @@ static void basic_range(int fd, unsigned flags) } igt_require(n); - obj[n].handle = gem_create(fd, 4096); + obj[n].handle = gem_create(fd, batch_size); obj[n].relocs_ptr = to_user_pointer(reloc); obj[n].relocation_count = n; gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));