similar to: Is Nouveau really using the io_reserve_lru?

Just a gentle ping on this. Already got the Acked-by from Daniel, but I need some of the nouveau guys to test this since I can only compile test it. Regards, Christian.

On Tue, 24 Sep 2019 at 22:19, Christian König <ckoenig.leichtzumerken at gmail.com> wrote: > > Hi guys, > > while working through more old TTM functionality I stumbled over the > io_reserve_lru. > > Basic idea is that when this flag is set the driver->io_mem_reserve() > callback can return -EAGAIN resulting in unmapping of other BOs. > > But Nouveau

Am 27.09.2019 20:07 schrieb Ilia Mirkin <imirkin at alum.mit.edu>: On Thu, Sep 26, 2019 at 5:44 PM Ben Skeggs <skeggsb at gmail.com> wrote: > > On Tue, 24 Sep 2019 at 22:19, Christian König > <ckoenig.leichtzumerken at gmail.com> wrote: > > > > Hi guys, > > > > while working through more old TTM functionality I stumbled over the > >

Hi guys, I've already send this out in September last year, but only got a response from Daniel. Could you guys please test this and tell me what you think about it? Basically I'm trying to remove all driver specific features from TTM which don't need to be inside the framework. Thanks, Christian.

While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. The patch should be functional correct, but is only compile tested! Signed-off-by: Christian König <christian.koenig at

Am 09.10.19 um 17:39 schrieb Daniel Vetter: > On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote: > [SNIP] >> +static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf) >> +{ >> + struct vm_area_struct *vma = vmf->vma; >> + struct ttm_buffer_object *bo = vma->vm_private_data; >> + pgprot_t prot; >> + vm_fault_t ret; >> + >> +

On Sat, 25 Jan 2020 at 00:30, Christian K?nig <ckoenig.leichtzumerken at gmail.com> wrote: > > From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> > > While working on TTM cleanups I've found that the io_reserve_lru used by > Nouveau is actually not working at all. > > In general we should remove driver specific handling from the memory > management,

Implementing those is completely unecessary. Signed-off-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 ----- drivers/gpu/drm/drm_gem_vram_helper.c | 5 ----- drivers/gpu/drm/qxl/qxl_ttm.c | 6 ------ drivers/gpu/drm/radeon/radeon_ttm.c | 5 ----- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 11 -----------

Hi guys, so I got some hardware and tested this and after hammering out tons of typos it now seems to work fine. Could you give it more testing? Thanks in advance, Christian

Without diving in any of the details, your commit message has me curious and concerned... In a "manager" kind of way, despite being neither a manager nor an insider or active contributor. ;-) On 24/01/2020 14:30, Christian K?nig wrote: > From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> > > While working on TTM cleanups I've found that the io_reserve_lru

We are trying to remove the io_lru handling and depend on zero init base, offset and addr here. v2: init addr as well Signed-off-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index e3931e515906..772c640a6046 100644 ---

On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote: > On Tue, Dec 19, 2017 at 8:45 AM, Christian König > <ckoenig.leichtzumerken at gmail.com> wrote: > > Am 19.12.2017 um 11:39 schrieb Michel Dänzer: > >> > >> On 2017-12-19 11:37 AM, Michel Dänzer wrote: > >>> > >>> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: > >>>>

Am 19.12.2017 um 11:39 schrieb Michel Dänzer: > On 2017-12-19 11:37 AM, Michel Dänzer wrote: >> On 2017-12-18 08:01 PM, Tobias Klausmann wrote: >>> On 12/18/17 7:06 PM, Mike Galbraith wrote: >>>> Greetings, >>>> >>>> Kernel bound workloads seem to trigger the below for whatever reason. >>>>   I only see this when beating up NFS.

From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> That is not used any more. v2: keep the NULL checks in TTM. Signed-off-by: Christian K?nig <christian.koenig at amd.com> Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/ttm/ttm_bo.c | 34 +-------- drivers/gpu/drm/ttm/ttm_bo_util.c | 113 +++--------------------------

Hi guys, I already tried this a few month ago, but since I don't have NVidia hardware its rather hard to test for me (need to get some ordered). Dave brought up the topic that we should probably try to move the handling into Nouveau once more, so I tried to fix the problem Ben reported and rebased on top of current drm-misc-next. Dave can you test this? At least in theory the approach

On Wed, May 20, 2020 at 10:43 AM Christian K?nig <ckoenig.leichtzumerken at gmail.com> wrote: > > Am 13.05.20 um 13:03 schrieb Christian K?nig: > > Unfortunately AGP is still to widely used as we could just drop support for using its GART. > > > > Not using the AGP GART also doesn't mean a loss in functionality since drivers will just fallback to the driver

From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. The patch should be functional correct, but is only compile

On Tue, May 12, 2020 at 4:16 AM Michel D?nzer <michel at daenzer.net> wrote: > > On 2020-05-11 10:12 p.m., Alex Deucher wrote: > > On Mon, May 11, 2020 at 1:17 PM Christian K?nig > > <ckoenig.leichtzumerken at gmail.com> wrote: > >> > >> AGP is deprecated for 10+ years now and not used any more on modern hardware. > >> > >> Old

From: Yonatan Maman <Ymaman at Nvidia.com> This patch series aims to enable Peer-to-Peer (P2P) DMA access in GPU-centric applications that utilize RDMA and private device pages. This enhancement is crucial for minimizing data transfer overhead by allowing the GPU to directly expose device private page data to devices such as NICs, eliminating the need to traverse system RAM, which is the

I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c