[Intel-gfx] [PATCH v2 12/15] drm/i915/create: apply ALLOC_GPU_ONLY by default
Thomas Hellström
thomas.hellstrom at linux.intel.com
Fri Feb 11 09:55:57 UTC 2022
On 2/11/22 10:52, Matthew Auld wrote:
> On Fri, 11 Feb 2022 at 09:49, Thomas Hellström
> <thomas.hellstrom at linux.intel.com> wrote:
>>
>> On 2/10/22 13:13, 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 at intel.com>
>>> Cc: Thomas Hellström <thomas.hellstrom at 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..cc9ddb943f96 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_GPU_ONLY;
>>> +
>> WRT previous review comment here, it would be easier to follow if the bo
>> was marked as a GPU only buffer regardless. Then for example capture and
>> other functions where it actually matters can choose to take action
>> based on, for example, whether the BAR is restricted or not?
> Yeah, I completely forgot about this, sorry. Will fix now.
Actually you did reply, but I forgot to reply to that :).
/Thomas
More information about the dri-devel
mailing list