Am 29.07.24 um 12:42 schrieb Michel Dänzer:
On 2024-07-26 17:25, Alex Deucher wrote:
On Fri, Jul 26, 2024 at 9:50 AM Alex Deucher <alexander.deuc...@amd.com> wrote:
This adds allocation latency, but aligns better with user
expectations. The latency should improve with the drm buddy
clearing patches that Arun has been working on.
Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index ebb3f87ef4f6..768840e8937d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -347,6 +347,10 @@ int amdgpu_gem_create_ioctl(struct drm_device *dev, void
*data,
return -EINVAL;
}
+ /* always clear VRAM */
+ if (args->in.domains & AMDGPU_GEM_DOMAIN_VRAM)
+ flags |= AMDGPU_GEM_CREATE_VRAM_CLEARED;
Alternatively, we can set AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE here,
although for cases like reboots, we probably want clear on create.
I agree. Thanks for doing this!
I strongly disagree. We have use cases were this will immediately become
a problem.
Especially we won't be able to hold latency requirements on boot for
certain projects any more.
Regards,
Christian.
Reviewed-by: Michel Dänzer <mdaen...@redhat.com>
BTW, maybe this allows reducing the use of
AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE, or even eliminating it altogether? Does
this leave any way for user space to access uncleared VRAM?
