From: Andrew Chew <achew-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: "nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>
Subject: Re: CUDA fixed VA allocations and sparse mappings
Date: Thu, 9 Jul 2015 17:31:01 -0700 [thread overview]
Message-ID: <20150710003101.GA7338@achew-linux64.nvidia.com> (raw)
In-Reply-To: <CAFCwf11pEc7vq0aPxdCRypzcbuaJRgWb_55q4ZUQPAvw5zXzHg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> 2. Use the GPUVM inside the GPU to access system memory. The
> limitation here is that the GPUVM uses 40-bit addresses, so the
> virtual address range must be in the lower 40-bit address range of the
> CPU. Access speed is limited by PCI-e bandwidth. Another limitation is
> that the system memory pages must be pinned as the GPU doesn't support
> page faults.
>
> The operation of reserving address space and BO creation is one IOCTL,
> while the mapping of the BO to the address space is a second IOCTL.
> There are of course unmap and free IOCTLs. The separation is done for
> a couple of reasons:
>
> 1. If the application knows that it wants to use only part of the
> memory area it allocated, then there is no point in pinning all the
> BOs. So, the application can map/unmap just part of the allocation.
>
> 2. If the application knows that it has finished using the BOs, and it
> also knows that it will use them later on, it can unmap the BOs (to
> make them unpinned) but not free them so the memory is still reserved
> (with its contents intact).
Yes, thanks Oled. I think this is pretty much exactly how I imagine things
to work.
I'll post my code soon and see what you guys think. There was some
misunderstanding on my part on how bo's work, so I need to rework some
stuff.
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
next prev parent reply other threads:[~2015-07-10 0:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150707004249.GC27924@achew-linux64.nvidia.com>
2015-07-07 15:29 ` [Nouveau] CUDA fixed VA allocations and sparse mappings Ilia Mirkin
[not found] ` <CAKb7UviePF2XcmyeKHQ2cv=hy=NZyYcMrWiTpajJxTFE+10LwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-07 17:27 ` Jerome Glisse
2015-07-09 9:26 ` [Nouveau] " Oded Gabbay
[not found] ` <CAFCwf11pEc7vq0aPxdCRypzcbuaJRgWb_55q4ZUQPAvw5zXzHg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-07-10 0:31 ` Andrew Chew [this message]
2015-07-07 18:47 ` Andrew Chew
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=20150710003101.GA7338@achew-linux64.nvidia.com \
--to=achew-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=dri-devel-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox