On 04/13/2015 03:22 PM, Joonas Lahtinen wrote:
On ma, 2015-04-13 at 12:32 +0100, Tvrtko Ursulin wrote:
Hi,
On 04/07/2015 01:23 PM, Joonas Lahtinen wrote:
Add a straightforward test that allocates a BO that is bigger than
(by 1 page currently) the mappable aperture, tests mmap access to it
by
On ma, 2015-04-13 at 12:32 +0100, Tvrtko Ursulin wrote:
> Hi,
>
> On 04/07/2015 01:23 PM, Joonas Lahtinen wrote:
> > Add a straightforward test that allocates a BO that is bigger than
> > (by 1 page currently) the mappable aperture, tests mmap access to it
> > by CPU directly and through GTT in se
Hi,
On 04/07/2015 01:23 PM, Joonas Lahtinen wrote:
Add a straightforward test that allocates a BO that is bigger than
(by 1 page currently) the mappable aperture, tests mmap access to it
by CPU directly and through GTT in sequence.
Currently it is expected for the GTT access to gracefully fail
Hi,
On ti, 2015-04-07 at 15:08 +0100, Chris Wilson wrote:
> On Tue, Apr 07, 2015 at 03:23:08PM +0300, Joonas Lahtinen wrote:
[snip]
> > +
> > + bo = gem_create(fd, huge_object_size);
> > +
> > + ptr_cpu = gem_mmap__cpu(fd, bo, 0, huge_object_size,
> > + PROT_READ | PR
On Tue, Apr 07, 2015 at 03:23:08PM +0300, Joonas Lahtinen wrote:
> static void
> +test_huge_bo(int fd)
> +{
> + uint32_t bo;
> + char *ptr_cpu;
> + char *ptr_gtt;
> + char *cpu_pattern;
> + uint64_t mappable_aperture_pages = gem_mappable_aperture_size() /
> +
Add a straightforward test that allocates a BO that is bigger than
(by 1 page currently) the mappable aperture, tests mmap access to it
by CPU directly and through GTT in sequence.
Currently it is expected for the GTT access to gracefully fail as
all objects are attempted to get pinned to GTT comp
