From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Bhardwaj, Rajneesh" <Rajneesh.Bhardwaj@amd.com>,
"Mahfooz, Hamza" <Hamza.Mahfooz@amd.com>,
"jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>,
"kherbst@redhat.com" <kherbst@redhat.com>,
"dakr@redhat.com" <dakr@redhat.com>,
"zackr@vmware.com" <zackr@vmware.com>,
"Olsak, Marek" <Marek.Olsak@amd.com>,
"linux-graphics-maintainer@vmware.com"
<linux-graphics-maintainer@vmware.com>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
"nouveau@lists.freedesktop.org" <nouveau@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
"spice-devel@lists.freedesktop.org"
<spice-devel@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [Nouveau] [PATCH 2/2] drm/amdgpu: use GTT only as fallback for VRAM|GTT
Date: Mon, 27 Nov 2023 19:59:16 +0100 [thread overview]
Message-ID: <c3809a89-31bc-4e5e-b0bf-538845e37f57@gmail.com> (raw)
In-Reply-To: <DS7PR12MB59339B73B38A4EFDB2A67A9FFEBDA@DS7PR12MB5933.namprd12.prod.outlook.com>
Am 27.11.23 um 17:47 schrieb Bhardwaj, Rajneesh:
> [AMD Official Use Only - General]
>
> -----Original Message-----
> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Hamza Mahfooz
> Sent: Monday, November 27, 2023 10:53 AM
> To: Christian König <ckoenig.leichtzumerken@gmail.com>; jani.nikula@linux.intel.com; kherbst@redhat.com; dakr@redhat.com; zackr@vmware.com; Olsak, Marek <Marek.Olsak@amd.com>; linux-graphics-maintainer@vmware.com; amd-gfx@lists.freedesktop.org; nouveau@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; virtualization@lists.linux.dev; spice-devel@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/amdgpu: use GTT only as fallback for VRAM|GTT
>
> On 11/27/23 09:54, Christian König wrote:
>> Try to fill up VRAM as well by setting the busy flag on GTT allocations.
>>
>> This fixes the issue that when VRAM was evacuated for suspend it's
>> never filled up again unless the application is restarted.
> I found the subject description a bit misleading. Maybe use a Fixes tag describing it is a fix for suspend resume regression other than that, looks good to me.
Well exactly that's the problem, this isn't really a fix and we also
don't want to backport it.
Basically the previous behavior was working as design, it's just that it
was never intended to be used like this.
>
> Acked-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com>
>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2893
Thanks,
Christian.
>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index aa0dd6dad068..ddc8fb4db678 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -173,6 +173,12 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, u32 domain)
>> abo->flags & AMDGPU_GEM_CREATE_PREEMPTIBLE ?
>> AMDGPU_PL_PREEMPT : TTM_PL_TT;
>> places[c].flags = 0;
>> + /*
>> + * When GTT is just an alternative to VRAM make sure that we
>> + * only use it as fallback and still try to fill up VRAM first.
>> + */
>> + if (domain & AMDGPU_GEM_DOMAIN_VRAM)
>> + places[c].flags |= TTM_PL_FLAG_BUSY;
>> c++;
>> }
>>
> --
> Hamza
>
prev parent reply other threads:[~2023-11-27 18:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 14:54 [Nouveau] TTM improvement and amdgpu fix Christian König
2023-11-27 14:54 ` [Nouveau] [PATCH 1/2] drm/ttm: replace busy placement with flags v3 Christian König
2023-11-27 14:54 ` [Nouveau] [PATCH 2/2] drm/amdgpu: use GTT only as fallback for VRAM|GTT Christian König
2023-11-27 15:53 ` Hamza Mahfooz
2023-11-27 16:47 ` Bhardwaj, Rajneesh
2023-11-27 18:59 ` Christian König [this message]
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=c3809a89-31bc-4e5e-b0bf-538845e37f57@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=Hamza.Mahfooz@amd.com \
--cc=Marek.Olsak@amd.com \
--cc=Rajneesh.Bhardwaj@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dakr@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=kherbst@redhat.com \
--cc=linux-graphics-maintainer@vmware.com \
--cc=nouveau@lists.freedesktop.org \
--cc=spice-devel@lists.freedesktop.org \
--cc=virtualization@lists.linux.dev \
--cc=zackr@vmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).