search for: drm_mm

Hi Patch "drm/nouveau: use drm_mm in preference to custom code doing the same thing" in nouveau tree introduced new deadlock possibility, for which lockdep complains loudly: [ 1541.070202] [drm] nouveau 0000:02:00.0: Allocating FIFO number 3 [ 1541.084772] [drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 3...

Am 27.01.23 um 15:44 schrieb Danilo Krummrich: > [SNIP] >>>> >>>> What you want is one component for tracking the VA allocations >>>> (drm_mm based) and a different component/interface for tracking the >>>> VA mappings (probably rb tree based). >>> >>> That's what the GPUVA manager is doing. There are gpuva_regions >>> which correspond to VA allocations and gpuvas which represent the >>...

On Sat, Jan 28, 2023 at 1:17 AM Christian K?nig <christian.koenig at amd.com> wrote: > > Am 27.01.23 um 15:44 schrieb Danilo Krummrich: > > [SNIP] > >>>> > >>>> What you want is one component for tracking the VA allocations > >>>> (drm_mm based) and a different component/interface for tracking the > >>>> VA mappings (probably rb tree based). > >>> > >>> That's what the GPUVA manager is doing. There are gpuva_regions > >>> which correspond to VA allocations and gpuvas which repre...

...eration-types-(-enum-amd_asic_type-and-enum-amd_chip_flags-)-Werror-Wenum-enum-conversion | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_ras.c:error:arithmetic-between-different-enumeration-types-(-enum-amdgpu_ras_block-and-enum-amdgpu_ras_mca_block-)-Werror-Wenum-enum-conversion | |-- drivers-gpu-drm-drm_mm.c:error:unused-function-drm_mm_interval_tree_insert-Werror-Wunused-function | |-- drivers-gpu-drm-drm_mm.c:error:unused-function-drm_mm_interval_tree_iter_next-Werror-Wunused-function | |-- drivers-gpu-drm-i915-display-intel_cursor.c:error:arithmetic-between-different-enumeration-types-(-enum-p...

On 1/27/23 16:17, Christian K?nig wrote: > Am 27.01.23 um 15:44 schrieb Danilo Krummrich: >> [SNIP] >>>>> >>>>> What you want is one component for tracking the VA allocations >>>>> (drm_mm based) and a different component/interface for tracking the >>>>> VA mappings (probably rb tree based). >>>> >>>> That's what the GPUVA manager is doing. There are gpuva_regions >>>> which correspond to VA allocations and gpuvas which represe...

...mmrich wrote: >> On 1/27/23 16:17, Christian K?nig wrote: >>> Am 27.01.23 um 15:44 schrieb Danilo Krummrich: >>>> [SNIP] >>>>>>> >>>>>>> What you want is one component for tracking the VA allocations >>>>>>> (drm_mm based) and a different component/interface for tracking >>>>>>> the VA mappings (probably rb tree based). >>>>>> >>>>>> That's what the GPUVA manager is doing. There are gpuva_regions >>>>>> which correspond to VA allo...

...> larger than the absolute VRAM would see degraded performance but > >> otherwise still work. > > You still need a list of unpinned bo, and the lru scan algorithm is > > just a few lines of code more than unpinning everything. Plus it'd be > > a neat example of the drm_mm scan logic. Given that some folks might > > think that not having lru evict si a problem and get them to type > > their own, I'd just add it. But up to you. Plus with ttm you get it no > > matter what. > > Well how about making an drm_lru component which just does the fo...

...viction strategy. Userspace with a WS > larger than the absolute VRAM would see degraded performance but > otherwise still work. You still need a list of unpinned bo, and the lru scan algorithm is just a few lines of code more than unpinning everything. Plus it'd be a neat example of the drm_mm scan logic. Given that some folks might think that not having lru evict si a problem and get them to type their own, I'd just add it. But up to you. Plus with ttm you get it no matter what. -Daniel > Best regards > Thomas > > > - no pipelining, no support for dma engines (it...

...viction strategy. Userspace with a WS > larger than the absolute VRAM would see degraded performance but > otherwise still work. You still need a list of unpinned bo, and the lru scan algorithm is just a few lines of code more than unpinning everything. Plus it'd be a neat example of the drm_mm scan logic. Given that some folks might think that not having lru evict si a problem and get them to type their own, I'd just add it. But up to you. Plus with ttm you get it no matter what. -Daniel > Best regards > Thomas > > > - no pipelining, no support for dma engines (it...

...on > > function to ttm (likely less ttm change). > > Can you solve your problem by being able to place the buffer at > certain location? We had the same need but managed to work around > it with a quick and dirty hack. > > Implementing that would mostly be about changing drm_mm.c to > handle placing buffers at certain locations. And in TTM core > being able to evict buffers that are in that place. That sounds like something that could solve an issue in Nouveau with nv04 card family. The following is hearsay, but I try to describe it. Of 32 MB of VRAM, the scanout...

Using -export-symbols-regex all private symbols are hidden, resulting in the following changes: libkms: removes all driver specific exports radeon: removes the bof_* exports nouveau: removes the abi16_* exports freedreno: remove the *kgsl_* and msm_* exports intel: removes the drm_mm* exports omap/exynos: unchanged as far as I can tell Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/exynos/Makefile.am b/exynos/Makefile.am index 0a2663a..0cd753d 100644 --- a/exynos/Makefile.am +++ b/exynos/Makefile.am @@ -7,7 +7,8 @@ AM_CFLAGS = \...

...g bo into vram - unpin framebuffers (which is just accounting, we don't want to move the bo on every flip!) - if a pin doesn't find enough space, move one of the unpinned bo still resident in vram out - no pipelining, no support for dma engines (it's all cpu copies anway) - a simple drm_mm should be good enough to manage the vram, no need for the ttm style abstraction over how memory is manged - also just bake in the lru eviction list and algorithm - probably good to have built-in support for redirecting the mmap between shmem and iomem. - anything that needs pipelining or copy e...

.../pl111/pl111_debugfs: Make local function 'pl111_debugfs_regs()' static drm/rockchip/dw-mipi-dsi-rockchip: Demote non-conformant kernel-doc headers drm/rockchip/rockchip_rgb: Consume our own header drm/rockchip/rockchip_lvds: Fix struct document formatting drm/selftests/test-drm_mm: Mark 'hole_end' as always_unused drm/selftests/test-drm_framebuffer: Remove set but unused variable 'fb' drm/selftests/test-drm_dp_mst_helper: Place 'struct drm_dp_sideband_msg_req_body' onto the heap drm/selftests/test-drm_dp_mst_helper: Move 'sideban...

...Vulkan > represents with a VKBuffer. If that's mangled into the same component/interface then I can say from experience that this is a pretty bad idea. We have tried something similar with radeon and it turned out horrible. What you want is one component for tracking the VA allocations (drm_mm based) and a different component/interface for tracking the VA mappings (probably rb tree based). amdgpu has even gotten so far that the VA allocations are tracked in libdrm in userspace. Regards, Christian. > > It serves two purposes: > > 1. It gives the kernel (in particular the...

...svm/uva/usm > (pointer-is-a-pointer) ? Because then we are talking about possible > 4KB mappings of 1 - 1.5 TB host server RAM (Implied in my question is > the assumption this can be used also for non-VK use-cases. Please tell > me if I'm totally wrong here). In V2 I switched from drm_mm to maple tree, which should improve handling of lots of entries. I also dropped the requirement for GPUVA entries to be backed by a valid GEM object. I think it can be used for non-VK use-cases. It basically just keeps track of mappings (not allocating them in the sense of finding a hole and p...

https://bugs.freedesktop.org/show_bug.cgi?id=36422 Summary: unable to hibernate with nouveau and NV11 [bisected] Product: xorg Version: unspecified Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at

...space with a WS >> larger than the absolute VRAM would see degraded performance but >> otherwise still work. > You still need a list of unpinned bo, and the lru scan algorithm is > just a few lines of code more than unpinning everything. Plus it'd be > a neat example of the drm_mm scan logic. Given that some folks might > think that not having lru evict si a problem and get them to type > their own, I'd just add it. But up to you. Plus with ttm you get it no > matter what. Well how about making an drm_lru component which just does the following (and nothing el...

...rt-symbols-regex" exactly that stuff we are trying to avoid in mesa? Christian. > > libkms: removes all driver specific exports > radeon: removes the bof_* exports > nouveau: removes the abi16_* exports > freedreno: remove the *kgsl_* and msm_* exports > intel: removes the drm_mm* exports > omap/exynos: unchanged as far as I can tell > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > > diff --git a/exynos/Makefile.am b/exynos/Makefile.am > index 0a2663a..0cd753d 100644 > --- a/exynos/Makefile.am > +++ b/exyn...

.../pl111/pl111_debugfs: Make local function 'pl111_debugfs_regs()' static drm/rockchip/dw-mipi-dsi-rockchip: Demote non-conformant kernel-doc headers drm/rockchip/rockchip_rgb: Consume our own header drm/rockchip/rockchip_lvds: Fix struct document formatting drm/selftests/test-drm_mm: Mark 'hole_end' as always_unused drm/selftests/test-drm_framebuffer: Remove set but unused variable 'fb' drm/selftests/test-drm_dp_mst_helper: Place 'struct drm_dp_sideband_msg_req_body' onto the heap drm/selftests/test-drm_dp_mst_helper: Move 'sideban...

...drm: use correct printf modifiers configure.ac: split -fvisibility and __attribute__((visibility)) checks radeon: move bof.[ch] out of libdrm_radeon radeon: add symbols test freedreno: annotate the private symbols freedreno: add symbols test intel: remove the drm_mm* symbol workarounds intel: remove unused mmFindBlock intel: annotate the private symbols intel: add symbols test nouveau: annotate the private symbols nouveau: add symbols test libkms: annotate private symbols libkms: add symbols test exynos: add symb...