| Message ID | 20220126152155.3070602-17-matthew.auld@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Initial support for small BAR recovery | expand |
On 1/26/22 16:21, Matthew Auld wrote: > Starting from DG2+, when dealing with LMEM, we assume that by default > all userspace allocations should be placed in the non-mappable portion > of LMEM. Note that dumb buffers are not included here, since these are > not "GPU accelerated" and likely need CPU access. > > In a later patch userspace will be able to provide a hint if CPU access > to the buffer is needed. > > Signed-off-by: Matthew Auld <matthew.auld@intel.com> > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> > --- > drivers/gpu/drm/i915/gem/i915_gem_create.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c b/drivers/gpu/drm/i915/gem/i915_gem_create.c > index 9402d4bf4ffc..e7456443f163 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c > @@ -424,6 +424,15 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void *data, > ext_data.n_placements = 1; > } > > + /* > + * TODO: add a userspace hint to force CPU_ACCESS for the object, which > + * can override this. > + */ > + if (!IS_DG1(i915) && (ext_data.n_placements > 1 || > + ext_data.placements[0]->type != > + INTEL_MEMORY_SYSTEM)) > + ext_data.flags |= I915_BO_ALLOC_TOPDOWN; Perhaps we should include DG1 here as well, so that the same paths are taken regardless whether this is only a test on DG1? > + > obj = __i915_gem_object_create_user_ext(i915, args->size, > ext_data.placements, > ext_data.n_placements,
On 03/02/2022 09:17, Thomas Hellström wrote: > > On 1/26/22 16:21, Matthew Auld wrote: >> Starting from DG2+, when dealing with LMEM, we assume that by default >> all userspace allocations should be placed in the non-mappable portion >> of LMEM. Note that dumb buffers are not included here, since these are >> not "GPU accelerated" and likely need CPU access. >> >> In a later patch userspace will be able to provide a hint if CPU access >> to the buffer is needed. >> >> Signed-off-by: Matthew Auld <matthew.auld@intel.com> >> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> >> --- >> drivers/gpu/drm/i915/gem/i915_gem_create.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c >> b/drivers/gpu/drm/i915/gem/i915_gem_create.c >> index 9402d4bf4ffc..e7456443f163 100644 >> --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c >> @@ -424,6 +424,15 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, >> void *data, >> ext_data.n_placements = 1; >> } >> + /* >> + * TODO: add a userspace hint to force CPU_ACCESS for the object, >> which >> + * can override this. >> + */ >> + if (!IS_DG1(i915) && (ext_data.n_placements > 1 || >> + ext_data.placements[0]->type != >> + INTEL_MEMORY_SYSTEM)) >> + ext_data.flags |= I915_BO_ALLOC_TOPDOWN; > > Perhaps we should include DG1 here as well, so that the same paths are > taken regardless whether this is only a test on DG1? I think the only reason was EXEC_CAPTURE, where atm we just reject anything marked with I915_BO_ALLOC_TOPDOWN, but that must not break existing DG1 uapi. > > > > >> + >> obj = __i915_gem_object_create_user_ext(i915, args->size, >> ext_data.placements, >> ext_data.n_placements,
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c b/drivers/gpu/drm/i915/gem/i915_gem_create.c index 9402d4bf4ffc..e7456443f163 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_create.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c @@ -424,6 +424,15 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void *data, ext_data.n_placements = 1; } + /* + * TODO: add a userspace hint to force CPU_ACCESS for the object, which + * can override this. + */ + if (!IS_DG1(i915) && (ext_data.n_placements > 1 || + ext_data.placements[0]->type != + INTEL_MEMORY_SYSTEM)) + ext_data.flags |= I915_BO_ALLOC_TOPDOWN; + obj = __i915_gem_object_create_user_ext(i915, args->size, ext_data.placements, ext_data.n_placements,
Starting from DG2+, when dealing with LMEM, we assume that by default all userspace allocations should be placed in the non-mappable portion of LMEM. Note that dumb buffers are not included here, since these are not "GPU accelerated" and likely need CPU access. In a later patch userspace will be able to provide a hint if CPU access to the buffer is needed. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_create.c | 9 +++++++++ 1 file changed, 9 insertions(+)