All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Matthew Wilcox <willy-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Ralph Campbell
	<rcampbell-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"Bridgman, John" <John.Bridgman-5C7GfCeVMHo@public.gmane.org>,
	Felix Kuehling <felix.kuehling-5C7GfCeVMHo@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
	Evgeny Baskakov
	<ebaskakov-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	christian.koenig-5C7GfCeVMHo@public.gmane.org
Subject: Re: [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau
Date: Tue, 13 Mar 2018 10:31:00 -0400	[thread overview]
Message-ID: <20180313143100.GC3828@redhat.com> (raw)
In-Reply-To: <20180313132940.GB3304-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>

On Tue, Mar 13, 2018 at 06:29:40AM -0700, Matthew Wilcox wrote:
> On Mon, Mar 12, 2018 at 11:14:47PM -0700, John Hubbard wrote:
> > Yes, on NVIDIA GPUs, the Host/FIFO unit is limited to 40-bit addresses, so
> > things such as the following need to be below (1 << 40), and also accessible 
> > to both CPU (user space) and GPU hardware. 
> >     -- command buffers (CPU user space driver fills them, GPU consumes them), 
> >     -- semaphores (here, a GPU-centric term, rather than OS-type: these are
> >        memory locations that, for example, the GPU hardware might write to, in
> >        order to indicate work completion; there are other uses as well), 
> >     -- a few other things most likely (this is not a complete list).
> 
> Is that a 40-bit virtual address limit or physical address limit?  I'm
> no longer sure who is addressing what memory through what mechanism ;-)
> 

Virtual address limit, those object get mapped into GPU page table but
the register/structure fields where you program those object's address
only are 32bits (the virtual address is shifted by 8bits for alignment).

Cheers,
Jérôme
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: John Hubbard <jhubbard@nvidia.com>,
	christian.koenig@amd.com, dri-devel@lists.freedesktop.org,
	nouveau@lists.freedesktop.org,
	Evgeny Baskakov <ebaskakov@nvidia.com>,
	linux-mm@kvack.org, Ralph Campbell <rcampbell@nvidia.com>,
	Felix Kuehling <felix.kuehling@amd.com>,
	"Bridgman, John" <John.Bridgman@amd.com>
Subject: Re: [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau
Date: Tue, 13 Mar 2018 10:31:00 -0400	[thread overview]
Message-ID: <20180313143100.GC3828@redhat.com> (raw)
In-Reply-To: <20180313132940.GB3304@bombadil.infradead.org>

On Tue, Mar 13, 2018 at 06:29:40AM -0700, Matthew Wilcox wrote:
> On Mon, Mar 12, 2018 at 11:14:47PM -0700, John Hubbard wrote:
> > Yes, on NVIDIA GPUs, the Host/FIFO unit is limited to 40-bit addresses, so
> > things such as the following need to be below (1 << 40), and also accessible 
> > to both CPU (user space) and GPU hardware. 
> >     -- command buffers (CPU user space driver fills them, GPU consumes them), 
> >     -- semaphores (here, a GPU-centric term, rather than OS-type: these are
> >        memory locations that, for example, the GPU hardware might write to, in
> >        order to indicate work completion; there are other uses as well), 
> >     -- a few other things most likely (this is not a complete list).
> 
> Is that a 40-bit virtual address limit or physical address limit?  I'm
> no longer sure who is addressing what memory through what mechanism ;-)
> 

Virtual address limit, those object get mapped into GPU page table but
the register/structure fields where you program those object's address
only are 32bits (the virtual address is shifted by 8bits for alignment).

Cheers,
Jerome

  parent reply	other threads:[~2018-03-13 14:31 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-10  3:21 [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau jglisse
2018-03-10  3:21 ` jglisse
2018-03-10  3:21 ` [RFC PATCH 01/13] drm/nouveau/vmm: enable page table iterator over non populated range jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 02/13] drm/nouveau/core/memory: add some useful accessor macros jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 03/13] drm/nouveau/core: define engine for handling replayable faults jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 04/13] drm/nouveau/mmu/gp100: allow gcc/tex to generate " jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 05/13] drm/nouveau/mc/gp100-: handle replayable fault interrupt jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 06/13] drm/nouveau/fault/gp100: initial implementation of MaxwellFaultBufferA jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 07/13] drm/nouveau: special mapping method for HMM jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 08/13] drm/nouveau: special mapping method for HMM (user interface) jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 09/13] drm/nouveau: add SVM through HMM support to nouveau client jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 10/13] drm/nouveau: add HMM area creation jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 11/13] drm/nouveau: add HMM area creation user interface jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 12/13] drm/nouveau: HMM area creation helpers for nouveau client jglisse
2018-03-10  3:21   ` jglisse
2018-03-10  3:21 ` [RFC PATCH 13/13] drm/nouveau: HACK FOR HMM AREA jglisse
2018-03-10  3:21   ` jglisse
     [not found] ` <20180310032141.6096-1-jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-03-10 15:01   ` [RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau Christian König
2018-03-10 15:01     ` Christian König
2018-03-10 17:55     ` Jerome Glisse
2018-03-10 17:55       ` Jerome Glisse
2018-03-12 17:30     ` Daniel Vetter
2018-03-12 17:30       ` Daniel Vetter
     [not found]       ` <20180312173009.GN8589-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
2018-03-12 17:50         ` Jerome Glisse
2018-03-12 17:50           ` Jerome Glisse
     [not found]           ` <20180312175057.GC4214-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2018-03-13  6:14             ` John Hubbard
2018-03-13  6:14               ` John Hubbard
2018-03-13 13:29               ` Matthew Wilcox
2018-03-13 13:29                 ` Matthew Wilcox
     [not found]                 ` <20180313132940.GB3304-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
2018-03-13 14:31                   ` Jerome Glisse [this message]
2018-03-13 14:31                     ` Jerome Glisse
     [not found]               ` <39139ff7-76ad-960c-53f6-46b57525b733-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2018-03-13 15:56                 ` Jerome Glisse
2018-03-13 15:56                   ` Jerome Glisse
2018-03-13 10:46             ` Daniel Vetter
2018-03-13 10:46               ` Daniel Vetter
2018-03-12 18:28     ` Felix Kuehling
2018-03-12 18:28       ` Felix Kuehling
     [not found]       ` <ef3d82cd-6c39-a50a-c4cb-d9d9ba13e31b-5C7GfCeVMHo@public.gmane.org>
2018-03-13 14:28         ` Jerome Glisse
2018-03-13 14:28           ` Jerome Glisse
2018-03-13 15:32           ` Felix Kuehling
2018-03-13 15:32             ` Felix Kuehling

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=20180313143100.GC3828@redhat.com \
    --to=jglisse-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=John.Bridgman-5C7GfCeVMHo@public.gmane.org \
    --cc=christian.koenig-5C7GfCeVMHo@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=ebaskakov-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=felix.kuehling-5C7GfCeVMHo@public.gmane.org \
    --cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=rcampbell-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=willy-wEGCiKHe2LqWVfeAwA7xHQ@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.