On Thu, 2009-11-05 at 20:04 +0200, Pekka Paalanen wrote:
On Wed, 4 Nov 2009 17:42:26 +
Jakob Bornecrantz ja...@vmware.com wrote:
Hi Jerome
On 4 nov 2009, at 15.58, Jerome Glisse wrote:
Note: For reference my issue is with cursor on old radeon hw,
cursor must be in the next
On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
We had to do a similar thing in the
Poulsbo driver and it turned out that we could save a significant amount of
CPU by using a delayed workqueue, collecting objects and destroying them
periodically.
Yes, indeed, we don't
On Thu, Jan 21, 2010 at 01:59:26PM +0100, Thomas Hellstrom wrote:
Jerome Glisse wrote:
On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
We had to do a similar thing in the
Poulsbo driver and it turned out that we could save a significant amount of
CPU by using a delayed
On Thu, Jan 21, 2010 at 04:14:39PM +0100, Luca Barbieri wrote:
I'm not sure I understand your proposal correctly.
It seems your proposoal is similar to mine, replacing the term fence
nodes with ttm transactions, but I'm not sure if I understand it
correctly
Here is some pseudocode for a
On Wed, Mar 9, 2011 at 1:54 PM, Nikolaus Rath nikol...@rath.org wrote:
Hello,
I would like to directly access some GPU memory. Is there some standard
way to do this when using the nouveau driver, e.g. by mmap'ing a
specific range of /dev/something, or do I have to write my own kernel
module
On Wed, Mar 9, 2011 at 2:18 PM, Nikolaus Rath nikol...@rath.org wrote:
Hello,
This isn't directly nouveau related, but since I was welcome on the IRC
channel I assume that I may post my question on the ML as well.
We are trying to use an NVidia Tesla card for highly parallel real time
On Wed, Dec 12, 2012 at 8:07 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Noticed while reviewing the fence locking in the radone pageflip
handler.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/ttm/ttm_bo_util.c |2 ++
1 file changed, 2 insertions(+)
diff
On Mon, Sep 29, 2014 at 09:43:02AM +0200, Daniel Vetter wrote:
On Fri, Sep 26, 2014 at 01:00:05PM +0300, Lauri Peltonen wrote:
Hi guys,
I'd like to start a new thread about explicit fence synchronization. This
time
with a Nouveau twist. :-)
First, let me define what I
On Tue, Jul 07, 2015 at 11:29:38AM -0400, Ilia Mirkin wrote:
On Mon, Jul 6, 2015 at 8:42 PM, Andrew Chew ac...@nvidia.com wrote:
Hello,
I am currently looking into ways to support fixed virtual address
allocations
and sparse mappings in nouveau, as a step towards supporting CUDA.
On Wed, Jul 08, 2015 at 10:51:55AM +1000, Ben Skeggs wrote:
On 8 July 2015 at 10:47, Andrew Chew ac...@nvidia.com wrote:
On Wed, Jul 08, 2015 at 10:37:34AM +1000, Ben Skeggs wrote:
On 8 July 2015 at 10:31, Andrew Chew ac...@nvidia.com wrote:
On Wed, Jul 08, 2015 at 10:18:36AM +1000, Ben
> Greetings,
>
> When box is earning its keep, nouveau/swiotlb grumble.. a LOT. The
> below is from master.today.
>
> [12594.640959] nouveau :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
> [12594.693000] nouveau :01:00.0: swiotlb buffer is full (sz: 2097152
> bytes)
>
On Mon, Mar 12, 2018 at 06:30:09PM +0100, Daniel Vetter wrote:
> On Sat, Mar 10, 2018 at 04:01:58PM +0100, Christian K??nig wrote:
[...]
> > > They are work underway to revamp nouveau channel creation with a new
> > > userspace API. So we might want to delay upstreaming until this lands.
> > >
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
> >
On Mon, Mar 12, 2018 at 11:14:47PM -0700, John Hubbard wrote:
> On 03/12/2018 10:50 AM, Jerome Glisse 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
>
On Mon, Mar 12, 2018 at 02:28:42PM -0400, Felix Kuehling wrote:
> On 2018-03-10 10:01 AM, Christian König wrote:
> >> To accomodate those we need to
> >> create a "hole" inside the process address space. This patchset have
> >> a hack for that (patch 13 HACK FOR HMM AREA), it reserves a range of
>
On Sat, Mar 10, 2018 at 04:01:58PM +0100, Christian König wrote:
> Good to have an example how to use HMM with an upstream driver.
I have tried to keep hardware specific bits and overal HMM logic separated
so people can use it as an example without needing to understand NVidia GPU.
I think i can
Hi, any pointer on how to debug this:
[ 19.741005] nouveau :01:00.0: enabling device (0541 -> 0543)
[ 19.741095] nouveau :01:00.0: Using 32-bit DMA via iommu
[ 19.741165] nouveau :01:00.0: NVIDIA GP108 (138000a1)
[ 19.752562] tg3 0004:01:00.0 enP4p1s0f0: renamed from eth0
[
On Thu, Mar 21, 2019 at 08:30:28PM +0100, Tobias Klausmann wrote:
> On 21.03.19 18:12, Jerome Glisse wrote:
> > On Thu, Mar 21, 2019 at 04:59:14PM +0100, Tobias Klausmann wrote:
> > > Hi,
> > >
> > > just for your information and maybe for some help: wit
On Thu, Mar 21, 2019 at 01:12:07PM -0400, Jerome Glisse wrote:
> On Thu, Mar 21, 2019 at 04:59:14PM +0100, Tobias Klausmann wrote:
> > Hi,
> >
> > just for your information and maybe for some help: with 5.1rc1 and SVM
> > enabled i see the following backtrace [1] whe
On Thu, Mar 21, 2019 at 04:59:14PM +0100, Tobias Klausmann wrote:
> Hi,
>
> just for your information and maybe for some help: with 5.1rc1 and SVM
> enabled i see the following backtrace [1] when the nouveau card (reverse
> prime) goes to sleep, for now i have papered over with [2] which leaves
On Sat, Jun 08, 2019 at 12:14:50AM +0530, Souptick Joarder wrote:
> Hi Jason,
>
> On Tue, May 21, 2019 at 12:27 AM Souptick Joarder
> wrote:
> >
> > Convert to use hmm_range_fault().
> >
> > Signed-off-by: Souptick Joarder
>
> Would you like to take it through your new hmm tree or do I
> need
On Wed, Apr 17, 2019 at 10:26:32PM +0800, Yue Haibing wrote:
> From: YueHaibing
>
> During randconfig builds, I occasionally run into an invalid configuration
>
> WARNING: unmet direct dependencies detected for DEVICE_PRIVATE
> Depends on [n]: ARCH_HAS_HMM_DEVICE [=n] && ZONE_DEVICE [=n]
>
On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote:
> When memory is migrated to the GPU it is likely to be accessed by GPU
> code soon afterwards. Instead of waiting for a GPU fault, map the
> migrated memory into the GPU page tables with the same access permissions
> as the source
On Mon, Jul 29, 2019 at 05:28:43PM +0300, Christoph Hellwig wrote:
> The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> where it can be replaced with a simple boolean local variable.
>
> Signed-off-by: Christoph Hellwig
NAK that flag is useful, for instance a anonymous vma
On Mon, Jul 29, 2019 at 05:28:35PM +0300, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma. Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks. This removes a lot
> of
On Mon, Jul 29, 2019 at 04:42:01PM -0700, Ralph Campbell wrote:
>
> On 7/29/19 7:28 AM, Christoph Hellwig wrote:
> > The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> > where it can be replaced with a simple boolean local variable.
> >
> > Signed-off-by: Christoph Hellwig
On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
> >
> > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
> > > On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote:
> > > > Section alignment
On Tue, Aug 13, 2019 at 05:58:52PM -0400, Jerome Glisse wrote:
> On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote:
> > When memory is migrated to the GPU it is likely to be accessed by GPU
> > code soon afterwards. Instead of waiting for a GPU fault, map the
>
On Thu, Aug 15, 2019 at 08:41:33PM +, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
>
> > So nor HMM nor driver should dereference the struct page (i do not
> > think any iommu driver would either),
>
> Er, they do technical
On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote:
> On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote:
> >
> > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
> > > >
&
On Thu, Aug 15, 2019 at 01:12:22PM -0700, Dan Williams wrote:
> On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse wrote:
> >
> > On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote:
> > > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote:
> > > >
&
On Tue, Jul 30, 2019 at 07:46:33AM +0200, Christoph Hellwig wrote:
> On Mon, Jul 29, 2019 at 07:30:44PM -0400, Jerome Glisse wrote:
> > On Mon, Jul 29, 2019 at 05:28:43PM +0300, Christoph Hellwig wrote:
> > > The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
On Fri, Nov 08, 2019 at 12:32:25AM +, Jason Gunthorpe wrote:
> On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> > On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> > > On Wed, Nov 06, 2019 at 09:08:07PM -0500, J
On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
>
> > >
> > > Extra credit: IMHO, this clearly deserves to all be in a new
> > > mmu_range_notifier.h
> > > header file,
On Wed, Nov 06, 2019 at 04:23:21PM -0800, John Hubbard wrote:
> On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
[...]
> > /**
> > * enum mmu_notifier_event - reason for the mmu notifier callback
> > @@ -32,6 +34,9 @@ struct mmu_notifier_range;
> > * access flags). User should soft dirty the
On Thu, Nov 07, 2019 at 10:33:02PM -0800, Christoph Hellwig wrote:
> On Thu, Nov 07, 2019 at 08:06:08PM +, Jason Gunthorpe wrote:
> > >
> > > enum mmu_range_notifier_event {
> > > MMU_NOTIFY_RELEASE,
> > > };
> > >
> > > ...assuming that we stay with "mmu_range_notifier" as a core name for
On Tue, Feb 09, 2021 at 09:35:20AM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 09, 2021 at 11:57:28PM +1100, Alistair Popple wrote:
> > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > >
> > > > Recent changes to pin_user_pages() prevent the creation of pinned pages
> > > >
37 matches
Mail list logo
