On 6/22/20 5:30 PM, John Hubbard wrote:
On 2020-06-22 16:38, Ralph Campbell wrote:
The OpenCL function clEnqueueSVMMigrateMem(), without any flags, will
migrate memory in the given address range to device private memory. The
source pages might already have been migrated to device private memory
On 2020-06-22 16:38, Ralph Campbell wrote:
The functions nvkm_vmm_ctor() and nvkm_mmu_ptp_get() are not called outside
of the file defining them so make them static.
Signed-off-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/m
On 2020-06-22 16:38, Ralph Campbell wrote:
The patch to add zero page migration to GPU memory inadvertantly included
inadvertently
part of a future change which broke normal page migration to GPU memory
by copying too much data and corrupting GPU memory.
Fix this by only copying one page inst
On 2020-06-22 16:38, Ralph Campbell wrote:
The OpenCL function clEnqueueSVMMigrateMem(), without any flags, will
migrate memory in the given address range to device private memory. The
source pages might already have been migrated to device private memory.
In that case, the source struct page is
On 6/22/20 4:54 PM, Yang Shi wrote:
On Mon, Jun 22, 2020 at 4:02 PM John Hubbard wrote:
On 2020-06-22 15:33, Yang Shi wrote:
On Mon, Jun 22, 2020 at 3:30 PM Yang Shi wrote:
On Mon, Jun 22, 2020 at 2:53 PM Zi Yan wrote:
On 22 Jun 2020, at 17:31, Ralph Campbell wrote:
On 6/22/20 1:10 PM,
As an update to the nouveau development community, the downstream fork of
Valgrind with a mmap tracing tool ("mmt") we maintain has been rebased
against the latest upstream release of Valgrind, v3.16.1
Code branch: https://github.com/envytools/valgrind/tree/mmt-3.16.1
Features of upstream Valgrin
These are based on 5.8.0-rc2 and intended for Ben Skeggs' nouveau tree.
I believe the changes can be queued for 5.8-rcX after being reviewed.
These were part of a larger series but I'm resending them separately as
suggested by Jason Gunthorpe.
https://lore.kernel.org/linux-mm/20200619215649.32297-1
The OpenCL function clEnqueueSVMMigrateMem(), without any flags, will
migrate memory in the given address range to device private memory. The
source pages might already have been migrated to device private memory.
In that case, the source struct page is not checked to see if it is
a device private
The patch to add zero page migration to GPU memory inadvertantly included
part of a future change which broke normal page migration to GPU memory
by copying too much data and corrupting GPU memory.
Fix this by only copying one page instead of a byte count.
Fixes: 9d4296a7d4b3 ("drm/nouveau/nouveau
The functions nvkm_vmm_ctor() and nvkm_mmu_ptp_get() are not called outside
of the file defining them so make them static.
Signed-off-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/
On 6/22/20 4:18 PM, Jason Gunthorpe wrote:
On Mon, Jun 22, 2020 at 11:10:05AM -0700, Ralph Campbell wrote:
On 6/22/20 10:25 AM, Jason Gunthorpe wrote:
On Fri, Jun 19, 2020 at 02:56:42PM -0700, Ralph Campbell wrote:
hmm_range_fault() returns an array of page frame numbers and flags for
how t
On Mon, Jun 22, 2020 at 11:10:05AM -0700, Ralph Campbell wrote:
>
> On 6/22/20 10:25 AM, Jason Gunthorpe wrote:
> > On Fri, Jun 19, 2020 at 02:56:42PM -0700, Ralph Campbell wrote:
> > > hmm_range_fault() returns an array of page frame numbers and flags for
> > > how the pages are mapped in the req
On 2020-06-22 15:33, Yang Shi wrote:
On Mon, Jun 22, 2020 at 3:30 PM Yang Shi wrote:
On Mon, Jun 22, 2020 at 2:53 PM Zi Yan wrote:
On 22 Jun 2020, at 17:31, Ralph Campbell wrote:
On 6/22/20 1:10 PM, Zi Yan wrote:
On 22 Jun 2020, at 15:36, Ralph Campbell wrote:
On 6/21/20 4:20 PM, Zi Yan wr
On 22 Jun 2020, at 17:31, Ralph Campbell wrote:
> On 6/22/20 1:10 PM, Zi Yan wrote:
>> On 22 Jun 2020, at 15:36, Ralph Campbell wrote:
>>
>>> On 6/21/20 4:20 PM, Zi Yan wrote:
On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
> Support transparent huge page migration to ZONE_DEVICE pri
On 6/21/20 5:15 PM, Zi Yan wrote:
On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
Transparent huge page allocation policy is controlled by several sysfs
variables. Rather than expose these to each device driver that needs to
allocate THPs, provide a helper function.
Signed-off-by: Ralph Campb
On 6/22/20 1:10 PM, Zi Yan wrote:
On 22 Jun 2020, at 15:36, Ralph Campbell wrote:
On 6/21/20 4:20 PM, Zi Yan wrote:
On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
Support transparent huge page migration to ZONE_DEVICE private memory.
A new flag (MIGRATE_PFN_COMPOUND) is added to the input
On 22 Jun 2020, at 15:36, Ralph Campbell wrote:
> On 6/21/20 4:20 PM, Zi Yan wrote:
>> On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
>>
>>> Support transparent huge page migration to ZONE_DEVICE private memory.
>>> A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to
>>> indicate
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp" so
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouve
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary reason
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just g
We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
1 file changed, 23 inse
Nvidia released some documentation on how CRC support works on their
GPUs, hooray!
So: this patch series implements said CRC support in nouveau, along with
adding some special debugfs interfaces for some relevant igt-gpu-tools
tests (already on the ML).
First - we add some new functionality to kt
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
Signed-off-by
Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to in
We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.
This patch contains no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Add some kind of vblank workers. The interface is similar to regular
delayed works, and is mostly based off kthread_work. It allows for
scheduling delayed works that execute once a particular vblank sequence
has passed. It also allows for accurate flushing of scheduled vblank
works - in that flushi
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's
On 6/21/20 4:20 PM, Zi Yan wrote:
On 19 Jun 2020, at 17:56, Ralph Campbell wrote:
Support transparent huge page migration to ZONE_DEVICE private memory.
A new flag (MIGRATE_PFN_COMPOUND) is added to the input PFN array to
indicate the huge page was fully mapped by the CPU.
Export prep_compoun
I see libwayland packages installed.
Ilia Mirkin schreef op 2020-06-22 20:18:
OK. That's not tearing. That's like a bad pitch on an image.
(Presumably you only find the second image, IMG_1968.jpg,
problematic?)
I'm guessing you're using a GL-based compositor, which I fully expect
to work poorly
On 6/22/20 10:22 AM, Jason Gunthorpe wrote:
On Fri, Jun 19, 2020 at 02:56:41PM -0700, Ralph Campbell wrote:
The SVM page fault handler groups faults into a range of contiguous
virtual addresses and requests hmm_range_fault() to populate and
return the page frame number of system memory mapped
Thanks. How do I find out what is used as compositor? I am using LXDE.
Ilia Mirkin schreef op 2020-06-22 20:18:
OK. That's not tearing. That's like a bad pitch on an image.
(Presumably you only find the second image, IMG_1968.jpg,
problematic?)
I'm guessing you're using a GL-based compositor, w
OK. That's not tearing. That's like a bad pitch on an image.
(Presumably you only find the second image, IMG_1968.jpg,
problematic?)
I'm guessing you're using a GL-based compositor, which I fully expect
to work poorly. Please try a non-compositing or XRender-based
compositing environment.
Cheers,
another picture
Ilia Mirkin schreef op 2020-06-22 19:27:
I suspect screen tearing (as it's usually defined) is to be expected.
Can you take a photo of what you're seeing, since I'm suspecting it's
more than regular screen tearing?
On Mon, Jun 22, 2020 at 12:08 PM Jeroen Diederen
wrote:
Hi I
On 6/22/20 10:25 AM, Jason Gunthorpe wrote:
On Fri, Jun 19, 2020 at 02:56:42PM -0700, Ralph Campbell wrote:
hmm_range_fault() returns an array of page frame numbers and flags for
how the pages are mapped in the requested process' page tables. The PFN
can be used to get the struct page with hmm
I suspect screen tearing (as it's usually defined) is to be expected.
Can you take a photo of what you're seeing, since I'm suspecting it's
more than regular screen tearing?
On Mon, Jun 22, 2020 at 12:08 PM Jeroen Diederen wrote:
>
> Hi Ilia,
>
> I experience screen tearing for both 64k and 4k pa
On Fri, Jun 19, 2020 at 02:56:42PM -0700, Ralph Campbell wrote:
> hmm_range_fault() returns an array of page frame numbers and flags for
> how the pages are mapped in the requested process' page tables. The PFN
> can be used to get the struct page with hmm_pfn_to_page() and the page size
> order ca
On Fri, Jun 19, 2020 at 02:56:41PM -0700, Ralph Campbell wrote:
> The SVM page fault handler groups faults into a range of contiguous
> virtual addresses and requests hmm_range_fault() to populate and
> return the page frame number of system memory mapped by the CPU.
> In preparation for supporting
On 6/22/20 5:39 AM, Jason Gunthorpe wrote:
On Fri, Jun 19, 2020 at 02:56:33PM -0700, Ralph Campbell wrote:
These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go
into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM
self tests. Patch 7-8 prepare nouveau for th
Hi Ilia,
I experience screen tearing for both 64k and 4k page size.
My iMac G5 has an nVidia Geforce FX 5200 Ultra GPU.
Regards,
Jeroen
Ilia Mirkin schreef op 2020-06-22 17:25:
Which GPU do you have? The NV40 AGP board (GeForce 6800) works
particularly poorly. However as long as you go with 4
Which GPU do you have? The NV40 AGP board (GeForce 6800) works
particularly poorly. However as long as you go with 4k pages (and
there's no real benefit to 64k pages for most applications), basic
things should work. I wouldn't recommend using a GL-based compositor
though.
Which distortion are you
nouveau_debugfs_strap_peek() calls pm_runtime_get_sync() that
increments the reference count. In case of failure, decrement the
ref count before returning the error.
Signed-off-by: Aditya Pakki
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Hi all,
I have been trying to solve nouveau issues on my iMac G5 for ages. As
far as I can understand it, there is a problem with nouveau and page
size mapping. I tried both 64K and 4K page size kernels and the the
result is always distorted video.
There is an old To-Do list, which says "fix t
nouveau_connector_detect() calls pm_runtime_get_sync and in turn
increments the reference count. In case of failure, decrement the
ref count before returning the error.
Signed-off-by: Aditya Pakki
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 +++-
1 file changed, 3 insertions(+), 1 deleti
nv50_disp_atomic_commit() calls calls pm_runtime_get_sync and in turn
increments the reference count. In case of failure, decrement the
ref count before returning the error.
Signed-off-by: Aditya Pakki
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++-
1 file changed, 3 insertions(+), 1 delet
On calling pm_runtime_get_sync() the reference count of the device
is incremented. In case of failure, decrement the
ref count before returning the error.
Signed-off-by: Aditya Pakki
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 8 ++--
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +++-
2 files c
nouveau_fbcon_open() calls calls pm_runtime_get_sync() that
increments the reference count. In case of failure, decrement the
ref count before returning the error.
Signed-off-by: Aditya Pakki
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
di
On Fri, Jun 19, 2020 at 02:56:33PM -0700, Ralph Campbell wrote:
> These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go
> into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM
> self tests. Patch 7-8 prepare nouveau for the meat of this series which
> adds support
48 matches
Mail list logo
