[Intel-gfx] [PATCH] igt: Test tiled bo for proper fence.

Daniel Vetter daniel at ffwll.ch
Thu Dec 18 12:31:43 PST 2014


On Thu, Dec 18, 2014 at 09:50:27AM -0800, Bob Paauwe wrote:
> When a tiled bo is allocated such that the actual size of the bo is
> larger than the region covered by the tiles.  For example allocating
> a Y-tiled bo that is 1920 x 1088 (15 x 34 tiles) results in a bo
> that is 0x200000 bytes instead of the 0x1FE000 bytes covered by the
> tiles. The fence needs to cover only the actual tiled region, otherwise
> writes beyond the tiled region may get converted to an address
> beyond the actual bo boundry.
> 
> This will test for that case by creating a tiled bo and a linear bo.
>   The linear bo is mapped directly after the tiled bo.
>   The linear bo is filed with a specific value (0x00)
>   The tiled bo is filled with a different value (0xff)
> 
> If any bytes in the linear bo get written with 0xff, then the
> fence allowed writing beyond the tiled bo boundry.
> 
> Signed-off-by: Bob Paauwe <bob.j.paauwe at intel.com>

Oh dear this is scary. Bunch of comments below.
-Daniel

> ---
>  tests/Makefile.sources           |   1 +
>  tests/gem_tiled_fence_overflow.c | 134 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 135 insertions(+)
>  create mode 100644 tests/gem_tiled_fence_overflow.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index d15a68b..c644fd3 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -136,6 +136,7 @@ TESTS_progs = \
>  	gem_tiled_pread_pwrite \
>  	gem_tiled_swapping \
>  	gem_tiled_wb \
> +	gem_tiled_fence_overflow \
>  	gem_tiling_max_stride \
>  	gem_unfence_active_buffers \
>  	gem_unref_active_buffers \
> diff --git a/tests/gem_tiled_fence_overflow.c b/tests/gem_tiled_fence_overflow.c
> new file mode 100644
> index 0000000..36482f7
> --- /dev/null
> +++ b/tests/gem_tiled_fence_overflow.c
> @@ -0,0 +1,134 @@
> +/*
> + * Copyright © 2014 Green Hills Software
> + * Copyright © 2009,2011,2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *    Bob Paauwe <bob.j.paauwe at intel.com>
> + *    Dan Hettena <danh at ghs.com>
> + *
> + */
> +
> +/** @file gem_tiled_fence_overflow.c
> + *
> + * This test tiled fenced regions to verify that they don't overflow
> + * into a flollowing allocation.  This can happen if the tiled region
> + * is less than the size of the object and the fence includes the
> + * "extra" bytes available beyond the tiled region.
> + *
> + * We check this by creating a tiled object followed by a linear object.
> + * The linear object if filled with 0x00 and then the tiled object is
> + * filled with 0xff.  If any of the bytes in the linear object are
> + * changed to 0xff, the fenced region is greater than than the tiled
> + * region, thus allowing us to write beyond the tiled buffer's allocation.
> + */

The newfangled way to describe tests is with IGT_TEST_DESCRIPTION. This
gets magically pulled into the documentation we generate since recently
for tests, see e.g.

http://people.freedesktop.org/~danvet/igt/igt-gem-tests.html
 
> +
> +#include <stdlib.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <fcntl.h>
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <sys/stat.h>
> +#include <sys/time.h>
> +
> +#include <drm.h>
> +
> +#include "ioctl_wrappers.h"
> +#include "drmtest.h"
> +#include "intel_bufmgr.h"
> +#include "intel_batchbuffer.h"
> +#include "intel_io.h"
> +#include "intel_chipset.h"
> +#include "igt_aux.h"
> +
> +static drm_intel_bufmgr *bufmgr;
> +static int width = 480, height = 1088;
> +
> +igt_simple_main
> +{
> +	drm_intel_bo *bo_tiled;
> +	drm_intel_bo *bo_linear;
> +	int fd, cpp = 4;
> +	int failed = 0;
> +	uint32_t tiled_mode = I915_TILING_Y;
> +	unsigned long pitch;
> +
> +	igt_skip_on_simulation();
> +
> +	fd = drm_open_any();
> +
> +
> +	bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
> +
> +	bo_tiled = drm_intel_bo_alloc_tiled(bufmgr, "bo_tiled",
> +										width, height, cpp, &tiled_mode,
> +										&pitch, BO_ALLOC_FOR_RENDER);
> +

Alignment gone wrong?

> +	igt_assert(tiled_mode == I915_TILING_Y);
> +
> +	if (drm_intel_gem_bo_map_gtt(bo_tiled) != 0)
> +		igt_assert(false);

Just push the condition into the igt_assert, if it fails the output will
be much more information than "Condition failed: false". Same for the ones
below.

> +	igt_info("Y-tiled buffer %d x %d cpp %d stride %ld size 0x%lx\n",
> +			 width, height, cpp, pitch, bo_tiled->size);

Codingstyle from i915 is to aling continuations with the opening (
Yeah, I'm nitpicking a bit ;-)

> +
> +	bo_linear = drm_intel_bo_alloc(bufmgr, "bo_linear", 0x1000, 4096);
> +
> +	if (drm_intel_gem_bo_map_gtt(bo_linear) != 0)
> +		igt_assert(false);
> +	igt_info("linear buffer size 0x%lx\n", bo_linear->size);
> +
> +
> +	/*
> +	 * Force the two buffers into the GTT such that the tiled
> +	 * buffer is first, followed by the linear buffer.
> +	 */
> +	*(volatile char *)bo_tiled->virtual;
> +	*(volatile char *)bo_linear->virtual;
> +
> +	/* Clear the linear buffer to all 0's */
> +	memset(bo_linear->virtual, 0, bo_linear->size);

All buffers are cleared to 0 at alloc time (well if they're not cached,
which isn't possible here).

> +
> +	/* Set the tiled buffer to all 0xff's */
> +	memset(bo_tiled->virtual, 0xff, bo_tiled->size);
> +	memset(bo_tiled->virtual, 0xdd, pitch * height);
> +
> +	/* Verify linear buffer is still all 0's by looking for a 0xff */
> +	if (memchr(bo_linear->virtual, 0xff, bo_linear->size) != NULL)
> +		failed = 1;

Imo just igt_assert here and reduce all the control flow.
> +
> +
> +	/* Clean up */
> +	drm_intel_bo_unreference(bo_linear);
> +	drm_intel_gem_bo_unmap_gtt(bo_linear);
> +	drm_intel_bo_unreference(bo_tiled);
> +	drm_intel_gem_bo_unmap_gtt(bo_tiled);
> +	drm_intel_bufmgr_destroy(bufmgr);
> +
> +	close(fd);
> +
> +	if (failed) {
> +		igt_info("Test failed\n");
> +		igt_fail(1);
> +	}
> +
> +	igt_info("Test passed\n");

If you want neat output imo better done in the library. We already do it
for subtests, for simple tests thus far the testrunner results where good
enough. But certainly can be patched up.

> +}
> -- 
> 2.1.0
> 

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the Intel-gfx mailing list