On 2024-04-02 10:17, Christian König wrote: > Am 26.03.24 um 15:53 schrieb Alex Deucher: >> On Tue, Mar 26, 2024 at 10:01 AM Alex Deucher <alexdeuc...@gmail.com> wrote: >>> On Tue, Mar 26, 2024 at 9:59 AM Paneer Selvam, Arunpravin >>>>>> @@ -501,6 +502,9 @@ static int amdgpu_vram_mgr_new(struct >>>>>> ttm_resource_manager *man, >>>>>> if (place->flags & TTM_PL_FLAG_CONTIGUOUS) >>>>>> vres->flags |= DRM_BUDDY_CONTIGUOUS_ALLOCATION; >>>>>> >>>>>> + if (bo->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED) >>>>>> + vres->flags |= DRM_BUDDY_CLEAR_ALLOCATION; >>>>> Is there any reason to not always do this? >>>> Here we are trying to keep a pool of cleared memory which are cleared on >>>> free path and that can given >>>> to the application which requires a zeroed memory. I think here if we >>>> set always clear the memory, >>>> we would go over the limit of cleared memory in that particular instance >>>> and the application should wait until >>>> the hardware clears the memory and this might impact the overall >>>> performance. >>> I'd like to have the driver always deliver cleared memory. >> Actually, I think we can just always set the flag in the allocation IOCTLs. > > We have use cases where that hurts as. Especially during boot when the > backing VRAM isn't cleared yet. > > That's one of the reasons why we never always cleared the memory.
Any such performance gain was only valid in the first place if the kernel delivering non-cleared memory to user space was considered acceptable, which it quite clearly isn't. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
