On 2024-07-29 13:14, Christian König wrote: > 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.deucher@xxxxxxx> 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.deucher@xxxxxxx> >>>> --- >>>> 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. Then it was only possible to achieve them by essentially cheating, leaking uncleared VRAM contents to user space. If that's acceptable for those use cases, you could maybe add some kind of opt-in mechanism for them. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
