From: Felix Kuehling <felix.kuehling-5C7GfCeVMHo@public.gmane.org>
To: "Christian König"
<ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH 01/11] drm/amdgpu: try allocating VRAM as power of two
Date: Mon, 10 Sep 2018 20:08:43 -0400 [thread overview]
Message-ID: <60b9c96a-d31d-cd61-df22-c8414f0166dc@amd.com> (raw)
In-Reply-To: <20180909180339.1910-2-christian.koenig-5C7GfCeVMHo@public.gmane.org>
This looks good. But it complicates something I've been looking at:
Remembering which process drm_mm_nodes last belonged to, so that they
don't need to be cleared next time they are allocated by the same
process. Having most nodes the same size (vram_page_split pages) would
make this very easy and efficient for the most common cases (large
allocations without any exotic address limitations or alignment
requirements).
Does anything else in this patch series depend on this optimization?
Regards,
Felix
On 2018-09-09 02:03 PM, Christian König wrote:
> Try to allocate VRAM in power of two sizes and only fallback to vram
> split sizes if that fails.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 52 +++++++++++++++++++++-------
> 1 file changed, 40 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index 9cfa8a9ada92..3f9d5d00c9b3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -124,6 +124,28 @@ u64 amdgpu_vram_mgr_bo_visible_size(struct amdgpu_bo *bo)
> return usage;
> }
>
> +/**
> + * amdgpu_vram_mgr_virt_start - update virtual start address
> + *
> + * @mem: ttm_mem_reg to update
> + * @node: just allocated node
> + *
> + * Calculate a virtual BO start address to easily check if everything is CPU
> + * accessible.
> + */
> +static void amdgpu_vram_mgr_virt_start(struct ttm_mem_reg *mem,
> + struct drm_mm_node *node)
> +{
> + unsigned long start;
> +
> + start = node->start + node->size;
> + if (start > mem->num_pages)
> + start -= mem->num_pages;
> + else
> + start = 0;
> + mem->start = max(mem->start, start);
> +}
> +
> /**
> * amdgpu_vram_mgr_new - allocate new ranges
> *
> @@ -176,10 +198,25 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager *man,
> pages_left = mem->num_pages;
>
> spin_lock(&mgr->lock);
> - for (i = 0; i < num_nodes; ++i) {
> + for (i = 0; pages_left >= pages_per_node; ++i) {
> + unsigned long pages = rounddown_pow_of_two(pages_left);
> +
> + r = drm_mm_insert_node_in_range(mm, &nodes[i], pages,
> + pages_per_node, 0,
> + place->fpfn, lpfn,
> + mode);
> + if (unlikely(r))
> + break;
> +
> + usage += nodes[i].size << PAGE_SHIFT;
> + vis_usage += amdgpu_vram_mgr_vis_size(adev, &nodes[i]);
> + amdgpu_vram_mgr_virt_start(mem, &nodes[i]);
> + pages_left -= pages;
> + }
> +
> + for (; pages_left; ++i) {
> unsigned long pages = min(pages_left, pages_per_node);
> uint32_t alignment = mem->page_alignment;
> - unsigned long start;
>
> if (pages == pages_per_node)
> alignment = pages_per_node;
> @@ -193,16 +230,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager *man,
>
> usage += nodes[i].size << PAGE_SHIFT;
> vis_usage += amdgpu_vram_mgr_vis_size(adev, &nodes[i]);
> -
> - /* Calculate a virtual BO start address to easily check if
> - * everything is CPU accessible.
> - */
> - start = nodes[i].start + nodes[i].size;
> - if (start > mem->num_pages)
> - start -= mem->num_pages;
> - else
> - start = 0;
> - mem->start = max(mem->start, start);
> + amdgpu_vram_mgr_virt_start(mem, &nodes[i]);
> pages_left -= pages;
> }
> spin_unlock(&mgr->lock);
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2018-09-11 0:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-09 18:03 Optimize VM handling a bit more Christian König
[not found] ` <20180909180339.1910-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-09-09 18:03 ` [PATCH 01/11] drm/amdgpu: try allocating VRAM as power of two Christian König
[not found] ` <20180909180339.1910-2-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-09-11 0:08 ` Felix Kuehling [this message]
[not found] ` <60b9c96a-d31d-cd61-df22-c8414f0166dc-5C7GfCeVMHo@public.gmane.org>
2018-09-11 6:49 ` Christian König
[not found] ` <9b61bb4c-4721-c8af-0810-4ecc18ed1ea4-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-09-11 7:37 ` Michel Dänzer
[not found] ` <46b7da24-4b04-7daf-e6c3-07e10ecb6fd6-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-09-11 7:46 ` Christian König
[not found] ` <d0af0309-e4f9-9825-fd30-9cf79ed5f823-5C7GfCeVMHo@public.gmane.org>
2018-09-11 7:55 ` Michel Dänzer
[not found] ` <5fd331d0-24ab-7540-2d0a-b227230743c0-otUistvHUpPR7s880joybQ@public.gmane.org>
2018-09-11 8:20 ` Christian König
[not found] ` <a3c91610-e5e2-c666-cfda-344f1f40485c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-09-11 8:25 ` Michel Dänzer
2018-09-11 14:27 ` Kuehling, Felix
[not found] ` <DM5PR12MB17073F8B673AEFC092FBA5B392040-2J9CzHegvk9TCtO+SvGBKwdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2018-09-11 14:48 ` Christian König
[not found] ` <2361b55f-ed56-bd42-b628-fc001d9ea300-5C7GfCeVMHo@public.gmane.org>
2018-09-11 22:25 ` Felix Kuehling
2018-09-11 9:50 ` Huang Rui
2018-09-11 11:16 ` Christian König
2018-09-09 18:03 ` [PATCH 02/11] drm/amdgpu: add amdgpu_vm_pt_parent helper Christian König
2018-09-09 18:03 ` [PATCH 03/11] drm/amdgpu: add amdgpu_vm_update_func Christian König
2018-09-09 18:03 ` [PATCH 04/11] drm/amdgpu: add some VM PD/PT iterators Christian König
[not found] ` <20180909180339.1910-5-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-09-11 1:51 ` Felix Kuehling
2018-09-11 2:38 ` Zhang, Jerry (Junwei)
2018-09-09 18:03 ` [PATCH 05/11] drm/amdgpu: use leaf iterator for allocating PD/PT Christian König
2018-09-09 18:03 ` [PATCH 06/11] drm/amdgpu: use dfs iterator to free PDs/PTs Christian König
2018-09-09 18:03 ` [PATCH 07/11] drm/amdgpu: use the DFS iterator in amdgpu_vm_invalidate_level Christian König
[not found] ` <20180909180339.1910-8-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-09-11 0:19 ` Felix Kuehling
2018-09-09 18:03 ` [PATCH 08/11] drm/amdgpu: use leaf iterator for filling PTs Christian König
2018-09-09 18:03 ` [PATCH 09/11] drm/amdgpu: meld together VM fragment and huge page handling Christian König
2018-09-09 18:03 ` [PATCH 10/11] drm/amdgpu: use the maximum possible fragment size on Vega/Raven Christian König
[not found] ` <20180909180339.1910-11-christian.koenig-5C7GfCeVMHo@public.gmane.org>
2018-09-11 0:45 ` Felix Kuehling
2018-09-09 18:03 ` [PATCH 11/11] drm/amdgpu: allow fragment processing for invalid PTEs Christian König
2018-09-11 2:17 ` Optimize VM handling a bit more Felix Kuehling
2018-09-11 2:39 ` Zhang, Jerry (Junwei)
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=60b9c96a-d31d-cd61-df22-c8414f0166dc@amd.com \
--to=felix.kuehling-5c7gfcevmho@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/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