From: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Ilia Mirkin <imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org>
Cc: "nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Alexandre Courbot
<gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 3/3] gk20a: use NOUVEAU_BO_GART as VRAM domain
Date: Thu, 13 Nov 2014 19:23:06 +0900 [thread overview]
Message-ID: <5464868A.6050009@nvidia.com> (raw)
In-Reply-To: <CAKb7UvhMw9pfDsvoGae2A+n9qJNBV5Vnxm4bn5tbK09GDcP_Dw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/30/2014 12:29 AM, Ilia Mirkin wrote:
> On Mon, Oct 27, 2014 at 6:34 AM, Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> GK20A does not have dedicated VRAM, therefore allocating in VRAM can be
>> sub-optimal and sometimes even harmful. Set its VRAM domain to
>> NOUVEAU_BO_GART so all objects are allocated in system memory.
>>
>> Signed-off-by: Alexandre Courbot <acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>> src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> index ac5823e4a8d5..ad143cd9a140 100644
>> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c
>> @@ -620,6 +620,16 @@ nvc0_screen_create(struct nouveau_device *dev)
>> return NULL;
>> pscreen = &screen->base.base;
>>
>> + /* Recognize chipsets with no VRAM */
>> + switch (dev->chipset) {
>> + /* GK20A */
>> + case 0xea:
>> + screen->base.vram_domain = NOUVEAU_BO_GART;
>
> I think you also want to set vidmem_bindings = 0... although
> potentially after the |= that's done below. Although I guess that
> constbuf + command args buf need to be |='d into the sysmem_bindings
> for this to work out well. That said, we don't really handle explicit
> migration well right now, and those PIPE_BIND_* are *incredibly*
> misleading and don't actually necessarily reflect the current usage.
> [I have some patches to improve the situation, but you don't really
> have to worry about that.]
In the light of that it could be that the vram_domain member I am
introducing is completely useless - if we set NV_VRAM_DOMAIN to be the
following:
#define NV_VRAM_DOMAIN(screen) ((screen)->vidmem_bindings == 0 ?
NOUVEAU_BO_GART : NOUVEAU_BO_VRAM)
then I suspect we can just live without it. I tested quickly and it
seems to work. Ilia, do you agree? Or could we imagine having GPUs with
VRAM for which none of the PIPE_BIND_* targets should reside in VRAM?
Also thinking, prior to setting vidmem_bindings to 0, shouldn't we also
do a "sysmem_bindings |= vidmem_bindings" to make sure all the set
bindings are tracked somewhere?
next prev parent reply other threads:[~2014-11-13 10:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-27 10:34 [PATCH 0/3] nouveau: support for custom VRAM domains Alexandre Courbot
[not found] ` <1414406099-21129-1-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-10-27 10:34 ` [PATCH 1/3] " Alexandre Courbot
2014-10-27 10:34 ` [PATCH 3/3] gk20a: use NOUVEAU_BO_GART as VRAM domain Alexandre Courbot
[not found] ` <1414406099-21129-4-git-send-email-acourbot-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-10-29 15:29 ` Ilia Mirkin
2014-11-05 10:23 ` Alexandre Courbot
2014-11-10 18:53 ` Ilia Mirkin
[not found] ` <CAKb7UvhMw9pfDsvoGae2A+n9qJNBV5Vnxm4bn5tbK09GDcP_Dw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-13 10:23 ` Alexandre Courbot [this message]
2014-10-27 10:34 ` [PATCH 2/3] nvc0: use NV_VRAM_DOMAIN() macro Alexandre Courbot
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=5464868A.6050009@nvidia.com \
--to=acourbot-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=imirkin-FrUbXkNCsVf2fBVCVOL8/A@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mesa-dev-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@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 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.