All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel.daenzer@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
	"Alex Deucher" <alexdeucher@gmail.com>,
	"Paneer Selvam, Arunpravin" <arunpravin.paneerselvam@amd.com>
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	alexander.deucher@amd.com, matthew.auld@intel.com,
	mario.limonciello@amd.com, felix.kuehling@amd.com
Subject: Re: [PATCH v9 2/3] drm/amdgpu: Enable clear page functionality
Date: Wed, 3 Apr 2024 11:01:03 +0200	[thread overview]
Message-ID: <715a00e7-f266-4af5-b7e2-b9a1d4275078@mailbox.org> (raw)
In-Reply-To: <38790fd5-afd3-4b56-ad14-7bd5897f6f9a@amd.com>

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 <alexdeucher@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


  reply	other threads:[~2024-04-03  9:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-18 21:40 [PATCH v9 1/3] drm/buddy: Implement tracking clear page feature Arunpravin Paneer Selvam
2024-03-18 21:40 ` [PATCH v9 2/3] drm/amdgpu: Enable clear page functionality Arunpravin Paneer Selvam
2024-03-19 10:28   ` Christian König
2024-03-19 11:41     ` Paneer Selvam, Arunpravin
2024-03-19 13:47       ` Christian König
2024-03-19 13:57         ` Paneer Selvam, Arunpravin
2024-03-26 13:38   ` Alex Deucher
2024-03-26 13:59     ` Paneer Selvam, Arunpravin
2024-03-26 14:01       ` Alex Deucher
2024-03-26 14:53         ` Alex Deucher
2024-03-27  8:23           ` Paneer Selvam, Arunpravin
2024-04-02  8:17           ` Christian König
2024-04-03  9:01             ` Michel Dänzer [this message]
2024-03-18 21:40 ` [PATCH v9 3/3] drm/tests: Add a test case for drm buddy clear allocation Arunpravin Paneer Selvam
2024-03-26 17:46   ` Matthew Auld
2024-03-25 13:37 ` [PATCH v9 1/3] drm/buddy: Implement tracking clear page feature Paneer Selvam, Arunpravin
2024-03-26 18:09 ` Matthew Auld
2024-03-28 16:07   ` Paneer Selvam, Arunpravin
2024-03-28 16:48     ` Matthew Auld
2024-04-01 11:07       ` Paneer Selvam, Arunpravin
2024-04-05 15:43         ` Matthew Auld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=715a00e7-f266-4af5-b7e2-b9a1d4275078@mailbox.org \
    --to=michel.daenzer@mailbox.org \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=arunpravin.paneerselvam@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=felix.kuehling@amd.com \
    --cc=mario.limonciello@amd.com \
    --cc=matthew.auld@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.