From: "Christian König" <christian.koenig@amd.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] Sparsely populated TTM bos
Date: Fri, 19 Nov 2021 17:35:53 +0100 [thread overview]
Message-ID: <5f292380-c3a2-3ec3-91bb-5e66a9290aac@amd.com> (raw)
In-Reply-To: <f73304f7-6ada-bcd2-97b3-c7898cbd166c@linux.intel.com>
Hi Thomas,
Am 19.11.21 um 15:28 schrieb Thomas Hellström:
> Hi, Christian,
>
> We have an upcoming use-case in i915 where one solution would be
> sparsely populated TTM bos.
>
> We had that at one point where ttm_tt pages were allocated on demand,
> but this time we'd rather be looking at multiple struct ttm_resources
> per bo and those resources could be from different managers.
>
> There might theoretically be other ways we can handle this use-case
> but I wanted to check with you whether this is something AMD is
> already looking into and if not, your general opinion.
oh, yes I've looked into this as well a very long time ago.
At that point the basic blocker was that we couldn't have different
cache setting for the same VMA, but I think that's fixed by now.
Another thing is that you essentially need to move the LRU handling into
the resource like I already planned to do anyway.
Regards,
Christian.
>
> Thanks,
> Thomas
>
>
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <christian.koenig@amd.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: Sparsely populated TTM bos
Date: Fri, 19 Nov 2021 17:35:53 +0100 [thread overview]
Message-ID: <5f292380-c3a2-3ec3-91bb-5e66a9290aac@amd.com> (raw)
In-Reply-To: <f73304f7-6ada-bcd2-97b3-c7898cbd166c@linux.intel.com>
Hi Thomas,
Am 19.11.21 um 15:28 schrieb Thomas Hellström:
> Hi, Christian,
>
> We have an upcoming use-case in i915 where one solution would be
> sparsely populated TTM bos.
>
> We had that at one point where ttm_tt pages were allocated on demand,
> but this time we'd rather be looking at multiple struct ttm_resources
> per bo and those resources could be from different managers.
>
> There might theoretically be other ways we can handle this use-case
> but I wanted to check with you whether this is something AMD is
> already looking into and if not, your general opinion.
oh, yes I've looked into this as well a very long time ago.
At that point the basic blocker was that we couldn't have different
cache setting for the same VMA, but I think that's fixed by now.
Another thing is that you essentially need to move the LRU handling into
the resource like I already planned to do anyway.
Regards,
Christian.
>
> Thanks,
> Thomas
>
>
next prev parent reply other threads:[~2021-11-19 16:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-19 14:28 [Intel-gfx] Sparsely populated TTM bos Thomas Hellström
2021-11-19 14:28 ` Thomas Hellström
2021-11-19 16:35 ` Christian König [this message]
2021-11-19 16:35 ` Christian König
2021-11-19 17:06 ` [Intel-gfx] " Daniel Vetter
2021-11-19 17:06 ` Daniel Vetter
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=5f292380-c3a2-3ec3-91bb-5e66a9290aac@amd.com \
--to=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=thomas.hellstrom@linux.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.