Message ID | 20220715111937.1245586-1-matthew.auld@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [i-g-t] tests/i915/gem_create: use 48b addressing | expand |
On Fri, Jul 15, 2022 at 12:19:37PM +0100, Matthew Auld wrote: > The object here could be very large (8G+), so make sure we allow using > the entire address space, to avoid sometimes hitting -ENOSPC. > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6446 > Signed-off-by: Matthew Auld <matthew.auld@intel.com> > Cc: Nirmoy Das <nirmoy.das@linux.intel.com> Yes, on DG1 we've often never entered > 32b offsets. Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> -- Zbigniew > --- > tests/i915/gem_create.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c > index 1b694c6a..ff022713 100644 > --- a/tests/i915/gem_create.c > +++ b/tests/i915/gem_create.c > @@ -538,7 +538,9 @@ static int upload(int fd, uint32_t handle) > * for sure placed in one of requested regions. > */ > exec[0].handle = handle; > + exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; > exec[1].handle = batch_create_size(fd, PAGE_SIZE); > + exec[1].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; > > return __gem_execbuf(fd, &execbuf); > } > -- > 2.36.1 >
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> On 7/15/2022 1:19 PM, Matthew Auld wrote: > The object here could be very large (8G+), so make sure we allow using > the entire address space, to avoid sometimes hitting -ENOSPC. > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6446 > Signed-off-by: Matthew Auld <matthew.auld@intel.com> > Cc: Nirmoy Das <nirmoy.das@linux.intel.com> > --- > tests/i915/gem_create.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c > index 1b694c6a..ff022713 100644 > --- a/tests/i915/gem_create.c > +++ b/tests/i915/gem_create.c > @@ -538,7 +538,9 @@ static int upload(int fd, uint32_t handle) > * for sure placed in one of requested regions. > */ > exec[0].handle = handle; > + exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; > exec[1].handle = batch_create_size(fd, PAGE_SIZE); > + exec[1].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; > > return __gem_execbuf(fd, &execbuf); > }
diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c index 1b694c6a..ff022713 100644 --- a/tests/i915/gem_create.c +++ b/tests/i915/gem_create.c @@ -538,7 +538,9 @@ static int upload(int fd, uint32_t handle) * for sure placed in one of requested regions. */ exec[0].handle = handle; + exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; exec[1].handle = batch_create_size(fd, PAGE_SIZE); + exec[1].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS; return __gem_execbuf(fd, &execbuf); }
The object here could be very large (8G+), so make sure we allow using the entire address space, to avoid sometimes hitting -ENOSPC. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6446 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@linux.intel.com> --- tests/i915/gem_create.c | 2 ++ 1 file changed, 2 insertions(+)