similar to: [PATCH] nouveau: set placement to original placement on uvmm validate.

From: Dave Airlie <airlied at redhat.com> dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8 was causing a remap operation like the below. op_remap: prev: 0000003fffed0000 00000000000f0000 00000000a5abd18a 0000000000000000 op_remap: next: op_remap: unmap: 0000003fffed0000 0000000000100000 0 op_map: map: 0000003ffffc0000 0000000000010000 000000005b1ba33c 00000000000e0000 This

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

"struct nouveau_job_ops" is not modified in these drivers. Constifying this structure moves some data to a read-only section, so increase overall security. In order to do it, "struct nouveau_job" and "struct nouveau_job_args" also need to be adjusted to this new const qualifier. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex

nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call their corresponding *_fini() counterpart. This can lead to nouveau_sched_fini() being called without struct nouveau_sched ever being initialized in the first place. Instead of embedding struct nouveau_sched into struct nouveau_cli and struct nouveau_chan_abi16, allocate struct nouveau_sched separately, such that we can check

Implement reference counting for struct drm_gpuvm. Signed-off-by: Danilo Krummrich <dakr at redhat.com> --- drivers/gpu/drm/drm_gpuvm.c | 56 +++++++++++++++++++++----- drivers/gpu/drm/nouveau/nouveau_uvmm.c | 20 ++++++--- include/drm/drm_gpuvm.h | 31 +++++++++++++- 3 files changed, 90 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/drm_gpuvm.c

On Thu, May 9, 2024 at 3:44?PM Mohamed Ahmed < mohamedahmedegypt2001 at gmail.com> wrote: > Allows PTE kind and tile mode on BO create with VM_BIND, > and adds a GETPARAM to indicate this change. This is needed to support > modifiers in NVK and ensure correctness when dealing with the nouveau > GL driver. > > The userspace modifiers implementation this is for can be found

On Wed, May 8, 2024 at 6:06?PM Mohamed Ahmed < mohamedahmedegypt2001 at gmail.com> wrote: > Allows PTE kind and tile mode on BO create with VM_BIND, > and adds a GETPARAM to indicate this change. This is needed to support > modifiers in NVK and ensure correctness when dealing with the nouveau > GL driver. > > The userspace modifiers implementation this is for can be found

Am 10.11.23 um 10:39 schrieb Thomas Hellstr?m: > > [SNIP] > I was thinking more of the general design of a base-class that needs > to be refcounted. Say a driver vm that inherits from gpu-vm, > gem_object and yet another base-class that supplies its own refcount. > What's the best-practice way to do refcounting? All base-classes > supplying a refcount of its own, or

On 11/10/23 11:42, Christian K?nig wrote: > Am 10.11.23 um 10:39 schrieb Thomas Hellstr?m: >> >> [SNIP] > >> I was thinking more of the general design of a base-class that needs >> to be refcounted. Say a driver vm that inherits from gpu-vm, >> gem_object and yet another base-class that supplies its own refcount. >> What's the best-practice way to

On 11/10/23 09:50, Christian K?nig wrote: > Am 09.11.23 um 19:34 schrieb Danilo Krummrich: >> On 11/9/23 17:03, Christian K?nig wrote: >>> Am 09.11.23 um 16:50 schrieb Thomas Hellstr?m: >>>> [SNIP] >>>>>> >>>> Did we get any resolution on this? >>>> >>>> FWIW, my take on this is that it would be possible to get

Am 09.11.23 um 19:34 schrieb Danilo Krummrich: > On 11/9/23 17:03, Christian K?nig wrote: >> Am 09.11.23 um 16:50 schrieb Thomas Hellstr?m: >>> [SNIP] >>>>> >>> Did we get any resolution on this? >>> >>> FWIW, my take on this is that it would be possible to get GPUVM to >>> work both with and without internal refcounting; If

On 11/9/23 17:03, Christian K?nig wrote: > Am 09.11.23 um 16:50 schrieb Thomas Hellstr?m: >> [SNIP] >>>> >> Did we get any resolution on this? >> >> FWIW, my take on this is that it would be possible to get GPUVM to work both with and without internal refcounting; If with, the driver needs a vm close to resolve cyclic references, if without that's not

nouveau_fence_emit() can fail before and after initializing the dma-fence and hence before and after initializing the dma-fence' kref. In order to avoid nouveau_fence_emit() potentially failing before dma-fence initialization pass the channel to nouveau_fence_new() already and perform the required check before even allocating the fence. While at it, restore the original behavior of

Am 13.08.20 um 10:36 schrieb Thomas Zimmermann: > GEM object functions deprecate several similar callback interfaces in > struct drm_driver. This patch replaces the per-driver callbacks with > per-instance callbacks in amdgpu. The only exception is gem_prime_mmap, > which is non-trivial to convert. > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> > --- >

GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in amdgpu. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ------

Hi Am 13.08.20 um 12:22 schrieb Christian K?nig: > Am 13.08.20 um 10:36 schrieb Thomas Zimmermann: >> GEM object functions deprecate several similar callback interfaces in >> struct drm_driver. This patch replaces the per-driver callbacks with >> per-instance callbacks in amdgpu. The only exception is gem_prime_mmap, >> which is non-trivial to convert. >> >>

GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in amdgpu. The only exception is gem_prime_mmap, which is non-trivial to convert. v2: * move object-function instance to amdgpu_gem.c (Christian) * set callbacks in amdgpu_gem_object_create() (Christian) Signed-off-by: Thomas

Am 15.09.20 um 16:59 schrieb Thomas Zimmermann: > GEM object functions deprecate several similar callback interfaces in > struct drm_driver. This patch replaces the per-driver callbacks with > per-instance callbacks in amdgpu. The only exception is gem_prime_mmap, > which is non-trivial to convert. > > v2: > * move object-function instance to amdgpu_gem.c (Christian) > *

The kbuild test bot complained about a new coccinelle warning nearby, which sparked a discussion about the assignment to 'memory' inside of the conditional expression. See Link below for the original post. Fix the assignment to silence the coccinelle warning and also make the code look a little nicer. Link: https://lists.freedesktop.org/archives/nouveau/2017-November/029242.html

This is a false positive, but I wonder if it is really necessary to put the assignment in the conditional test expression. julia ---------- Forwarded message ---------- Date: Tue, 28 Nov 2017 13:23:36 +0800 From: kbuild test robot <fengguang.wu at intel.com> To: kbuild at 01.org Cc: Julia Lawall <julia.lawall at lip6.fr> Subject: [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci