On Thu, 18 Dec 2014 21:31:43 +0100 Daniel Vetter <daniel@xxxxxxxx> wrote: > 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@xxxxxxxxx> > > 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@xxxxxxxxx> > > + * Dan Hettena <danh@xxxxxxx> > > + * > > + */ > > + > > +/** @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 Ok, the one test I uses as reference didn't have this. Added in v2. > > > + > > +#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). Yeah, I guess it's not necessary and may using the word "Clear" in the comment isn't quite right. The value set could be anything but having it cleared is convenient. I'll drop this and improve the comment below to reflect that the linear buffer is cleared by default. > > > + > > + /* 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. So it's ok to skip all the unref / unmap when the test fails? > > + > > + > > + /* 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@xxxxxxxxxxxxxxxxxxxxx > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
