dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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