[Intel-gfx] [igt-dev] [PATCH igt] igt/gem_softpin: Only expect EINVAL for color-overlaps for user objects

Chris Wilson chris at chris-wilson.co.uk
Mon Feb 26 21:27:56 UTC 2018


Quoting Ville Syrjälä (2018-02-26 21:22:03)
> On Mon, Feb 26, 2018 at 08:54:47PM +0000, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-02-24 18:54:04)
> > > If the specified object can not fit into the GTT due to overlap with a
> > > neighbouring pinned object (not part of the execobjects[]), we expect to
> > > fail with ENOSPC (as we cannot evict, rather than EINVAL for the user
> > > error in a badly constructed execobjects[]). To prevent the tests
> > > causing overlap with other external objects expand the test hole by a
> > > page on either side.
> > > 
> > > (Setting up the system to deliberately hit ENOSPC is trickier as for
> > > example it requires pinned an object into the scanout with enough free
> > > space on either side to test.)
> > 
> > Anybody? I know it's an esoteric part of ancient HW that no one cares
> > about...
> > -Chris
> > 
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > ---
> > >  tests/gem_softpin.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c
> > > index 99388599..23f93623 100644
> > > --- a/tests/gem_softpin.c
> > > +++ b/tests/gem_softpin.c
> > > @@ -302,11 +302,11 @@ static void test_evict_snoop(int fd)
> > >  
> > >         /* Find a hole */
> > >         memset(object, 0, sizeof(object));
> > > -       object[0].handle = gem_create(fd, 3*4096);
> > > +       object[0].handle = gem_create(fd, 5*4096);
> > >         gem_write(fd, object[0].handle, 0, &bbe, sizeof(bbe));
> > >         gem_execbuf(fd, &execbuf);
> > >         gem_close(fd, object[0].handle);
> > > -       hole = object[0].offset;
> > > +       hole = object[0].offset + 4096;
> 
> I didn't double check the ENOSPC vs. EINVAL details, but a guard page on
> each side makes sense to me here.

It's enough to make me regret trying to discern the difference :)
EINVAL was for if the user's execobject[] conflicts with itself (a user
error), ENOSPC if we couldn't fit the object into the hole (something we
couldn't expect the user to predict).

Thanks,
-Chris


More information about the Intel-gfx mailing list