On Tue, Jun 23, 2015 at 01:21:29PM +0100, Michel Thierry wrote:
> +static void reusebo_and_compare_offsets(uint32_t fd,
> + uint64_t buf_size)
> +{
> + uint32_t bo;
> + uint64_t offset, offset2;
> +
> + bo = gem_create(fd, buf_size);
> + /* support 48b addresses */
> + offset = exec_and_get_offset(fd, bo, 0);
> + gem_sync(fd, bo);
What are the sync for?
> + /* require 32b address */
> + offset2 = exec_and_get_offset(fd, bo, 1);
> + gem_sync(fd, bo);
> +
> + igt_assert(is_32b(offset2));
> + igt_assert_neq(offset, offset2);
Nothing was preventing the first allocation from being a is_32b()
afaict. At least you should have asserted that the top-down allocation
placed it outside of the 32b zone to begin with.
Also there is a requirement that 32b allocations are wholly inside the
32b zone.
> + gem_close(fd, bo);
> +}
> +
> +static void flinkbo_and_compare_offsets(uint32_t fd, uint32_t fd2,
> + uint64_t buf_size)
> +
> +static void createbo_and_compare_offsets(uint32_t fd, uint32_t fd2,
> + uint64_t buf_size,
> + bool needs_32b, bool needs_32b2)
> +{
> + uint32_t bo, bo2;
> + uint64_t offset, offset2;
> +
> + bo = gem_create(fd, buf_size);
> + offset = exec_and_get_offset(fd, bo, needs_32b);
> + gem_sync(fd, bo);
> +
> + bo2 = gem_create(fd2, buf_size);
> + offset2 = exec_and_get_offset(fd2, bo2, needs_32b2);
> + gem_sync(fd2, bo2);
> +
> + if (needs_32b == needs_32b2)
> + igt_assert_eq(offset, offset2);
> + else
> + igt_assert_neq(offset, offset2);
Again there is a large number of assumptions about the internal
behaviour that I think can (a) be made explicity, or (b) be eliminated
entirely.
But first I think these are poor tests, since the two ctx are supposed to
be independent, making assertions between them is wrong.
What you need to focus on testing is that an object executed without the
full-48b flag is moved into the 32b zone no matter it's starting
position - or an error is generated (e.g. a 4G+ object, or 4G+ alignment).
We don't want that flag to imply anything else about the internal
implementation.
(Note this can be speed up on !llc if we have pad-to-size.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
