similar to: [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

On 2/23/23 20:09, Liam R. Howlett wrote: > * Danilo Krummrich <dakr at redhat.com> [230222 13:13]: >> On 2/21/23 19:20, Liam R. Howlett wrote: >>> * Danilo Krummrich <dakr at redhat.com> [230217 08:45]: >>>> Add infrastructure to keep track of GPU virtual address (VA) mappings >>>> with a decicated VA space manager implementation.

On 3/2/23 03:38, Liam R. Howlett wrote: > * Danilo Krummrich <dakr at redhat.com> [230227 08:17]: > > ... >>>> Would this variant be significantly more efficient? >>> >>> Well, what you are doing is walking the tree to see if there's anything >>> there... then re-walking the tree to store it. So, yes, it's much more >>>

On 7/7/23 09:57, Boris Brezillon wrote: > On Thu, 6 Jul 2023 20:26:42 +0200 > Boris Brezillon <boris.brezillon at collabora.com> wrote: > >> On Fri, 30 Jun 2023 00:25:18 +0200 >> Danilo Krummrich <dakr at redhat.com> wrote: >> >>> +#ifdef CONFIG_LOCKDEP >>> +typedef struct lockdep_map *lockdep_map_p; >>> +#define

So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM

On 2/28/23 17:24, Liam R. Howlett wrote: > * Danilo Krummrich <dakr at redhat.com> [230227 21:17]: >> On Tue, Feb 21, 2023 at 01:20:50PM -0500, Liam R. Howlett wrote: >>> * Danilo Krummrich <dakr at redhat.com> [230217 08:45]: >>>> Add infrastructure to keep track of GPU virtual address (VA) mappings >>>> with a decicated VA space manager

On 2/17/23 19:34, Liam R. Howlett wrote: > * Danilo Krummrich <dakr at redhat.com> [230217 08:44]: >> Split up the MA_STATE() macro such that components using the maple tree >> can easily inherit from struct ma_state and build custom tree walk >> macros to hide their internals from users. >> >> Example: >> >> struct sample_iter { >> struct

Hi, On 8/31/23 13:18, Danilo Krummrich wrote: > On Thu, Aug 31, 2023 at 11:04:06AM +0200, Thomas Hellstr?m (Intel) wrote: >> Hi! >> >> On 8/30/23 17:00, Danilo Krummrich wrote: >>> On Wed, Aug 30, 2023 at 03:42:08PM +0200, Thomas Hellstr?m (Intel) wrote: >>>> On 8/30/23 14:49, Danilo Krummrich wrote: >>>>> Hi Thomas, >>>>>

Hi Donald, On 7/6/23 17:45, Donald Robson wrote: > On Fri, 2023-06-30 at 00:25 +0200, Danilo Krummrich wrote: >> >> +#ifdef CONFIG_LOCKDEP >> +typedef struct lockdep_map *lockdep_map_p; >> +#define drm_gpuva_manager_ext_assert_held(mgr) \ >> + lockdep_assert(lock_is_held((mgr)->ext_lock) != LOCK_STATE_NOT_HELD) >> +/** >> + *

This commit adds a function to dump a DRM GPU VA space and a macro for drivers to register the struct drm_info_list 'gpuvas' entry. Most likely, most drivers might maintain one DRM GPU VA space per struct drm_file, but there might also be drivers not having a fixed relation between DRM GPU VA spaces and a DRM core infrastructure, hence we need the indirection via the driver iterating

On 2/22/23 11:25, Christian K?nig wrote: > Am 17.02.23 um 14:44 schrieb Danilo Krummrich: <snip> >> +/** >> + * DOC: Overview >> + * >> + * The DRM GPU VA Manager, represented by struct drm_gpuva_manager >> keeps track >> + * of a GPU's virtual address (VA) space and manages the >> corresponding virtual >> + * mappings represented by

Am 22.02.23 um 17:40 schrieb Danilo Krummrich: > On 2/22/23 16:14, Christian K?nig wrote: >> Am 22.02.23 um 16:07 schrieb Danilo Krummrich: >>> On 2/22/23 11:25, Christian K?nig wrote: >>>> Am 17.02.23 um 14:44 schrieb Danilo Krummrich: >>> >>> <snip> >>> >>>>> +/** >>>>> + * DOC: Overview

On 6/23/23 09:16, Christian K?nig wrote: > Am 22.06.23 um 17:07 schrieb Danilo Krummrich: >> On 6/22/23 17:04, Danilo Krummrich wrote: >>> On 6/22/23 16:42, Christian K?nig wrote: >>>> Am 22.06.23 um 16:22 schrieb Danilo Krummrich: >>>>> On 6/22/23 15:54, Christian K?nig wrote: >>>>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich:

Dear all, I have the following object: > print(x) An object of class "matrix.csr" Slot "ra": [1] 0.992056718 1.000000000 1.000000000 1.000000000 1.000000000 1.000000000 [7] 1.000000000 1.000000000 1.000000000 1.000000000 1.000000000 1.000000000 [13] 1.000000000 1.000000000 1.000000000 1.000000000 1.000000000 1.000000000 [19] 1.000000000 1.000000000 1.000000000

Dear all, I have a binned data that looks like this: > dat (-1,9] (9,19] (19,29] (29,39] (39,49] (49,59] (59,69] (69,79] 10063374 79 16 4 3 4 4 3 (79,89] (89,99] 6 2 I tried to plot a histogram overlayed with curve. With the following snippet: library(lattice) pdf("myfile.pdf") hist(dat)

Dear all, I have a simple plot using "gridBase" like this. The problem occurs whenever I execute this code there is always a blank page created before the actual plot. How can we disable that blank page? I am using: R version 2.7.2 (2008-08-25) and gridBase version: 0.4-3 __ BEGIN__ library(grid) library(gridBase) opar <- par(no.readonly=TRUE) par(opar) grid.newpage()