Re: [PATCH v2 0/2] doc: uapi: Document dma-buf interop design & semantics

, thanks for writing this up. I think it is great to have all this knowledge collected in one place. For the series: Reviewed-by: James Jones I think it'd be great to have input/links/reflections from other subsystems as well here. Agreed, though I'll reiterate my comment on the v1 series

Re: DMA-heap driver hints

On 1/24/23 15:14, T.J. Mercier wrote: On Mon, Jan 23, 2023 at 11:49 PM Christian König wrote: Am 24.01.23 um 04:56 schrieb James Jones: On 1/23/23 08:58, Laurent Pinchart wrote: Hi Christian, On Mon, Jan 23, 2023 at 05:29:18PM +0100, Christian König wrote: Am 23.01.23 um 14:55 schrieb

Re: DMA-heap driver hints

On 1/23/23 08:58, Laurent Pinchart wrote: Hi Christian, On Mon, Jan 23, 2023 at 05:29:18PM +0100, Christian König wrote: Am 23.01.23 um 14:55 schrieb Laurent Pinchart: Hi Christian, CC'ing James as I think this is related to his work on the unix device memory allocator ([1]). Thank you for

Re: [PATCH] doc: gpu: Add document describing buffer exchange

On 9/8/21 2:44 AM, Simon Ser wrote: stride I think what's clear is: - Per-plane property - In bytes - Offset between two consecutive rows How that applies to weird YUV formats is the tricky question… Btw. there was a fun argument whether the same modifier value could mean

Re: [PATCH] doc: gpu: Add document describing buffer exchange

On 9/6/21 5:28 AM, Simon Ser wrote: Since there's a lot of confusion around this, document both the rules and the best practice around negotiating, allocating, importing, and using buffers when crossing context/process/device/subsystem boundaries. This ties up all of dmabuf, formats and

Re: [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes

Gah, yes, good catch. Reviewed-by: James Jones On 1/18/21 5:54 PM, Lyude Paul wrote: Nvidia hardware doesn't actually support using tiling formats with the cursor plane, only linear is allowed. In the future, we should write a testcase for this. Fixes: c586f30bf74c ("drm/nouveau/kms

Re: [git pull] drm for 5.8-rc1

On 9/1/20 3:59 AM, Karol Herbst wrote: On Tue, Sep 1, 2020 at 9:13 AM Daniel Vetter wrote: On Tue, Aug 18, 2020 at 04:37:51PM +0200, Thierry Reding wrote: On Fri, Aug 14, 2020 at 07:25:17PM +0200, Daniel Vetter wrote: On Fri, Aug 14, 2020 at 7:17 PM Daniel Stone wrote: Hi, On Fri, 14

Re: [RFC] Experimental DMA-BUF Device Heaps

On 8/23/20 1:46 PM, Laurent Pinchart wrote: Hi James, On Sun, Aug 23, 2020 at 01:04:43PM -0700, James Jones wrote: On 8/20/20 1:15 AM, Ezequiel Garcia wrote: On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote: On 8/17/20 8:18 AM, Brian Starkey wrote: On Sun, Aug 16, 2020 at 02:22:46PM

Re: [RFC] Experimental DMA-BUF Device Heaps

On 8/20/20 1:15 AM, Ezequiel Garcia wrote: On Mon, 2020-08-17 at 20:49 -0700, James Jones wrote: On 8/17/20 8:18 AM, Brian Starkey wrote: Hi Ezequiel, On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote: This heap is basically a wrapper around DMA-API dma_alloc_attrs, which

Re: [RFC] Experimental DMA-BUF Device Heaps

On 8/17/20 8:18 AM, Brian Starkey wrote: Hi Ezequiel, On Sun, Aug 16, 2020 at 02:22:46PM -0300, Ezequiel Garcia wrote: This heap is basically a wrapper around DMA-API dma_alloc_attrs, which will allocate memory suitable for the given device. The implementation is mostly a port of the

Re: [git pull] drm for 5.8-rc1

server git because of this commit: https://gitlab.freedesktop.org/xorg/xserver/-/commit/9b8999411033c9473cd68e92e4690a91aecf5b95 On Wed, Aug 12, 2020 at 8:25 PM James Jones wrote: On 8/12/20 10:40 AM, Alyssa Rosenzweig wrote: ...and in merging my code with Alyssa's new panfrost format modifier

Re: [git pull] drm for 5.8-rc1

On 8/12/20 10:40 AM, Alyssa Rosenzweig wrote: ...and in merging my code with Alyssa's new panfrost format modifier support, I see panfrost does the opposite of this and treats a format modifier list of only INVALID as "don't care". I modeled the new nouveau behavior on the Iris driver. Now I'm

Re: [git pull] drm for 5.8-rc1

On 8/12/20 10:10 AM, Karol Herbst wrote: On Wed, Aug 12, 2020 at 7:03 PM James Jones wrote: On 8/12/20 5:37 AM, Ilia Mirkin wrote: On Wed, Aug 12, 2020 at 8:24 AM Karol Herbst wrote: On Wed, Aug 12, 2020 at 12:43 PM Karol Herbst wrote: On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst

Re: [git pull] drm for 5.8-rc1

On 8/12/20 5:37 AM, Ilia Mirkin wrote: On Wed, Aug 12, 2020 at 8:24 AM Karol Herbst wrote: On Wed, Aug 12, 2020 at 12:43 PM Karol Herbst wrote: On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote: On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote: Sorry for the slow reply here

Re: [git pull] drm for 5.8-rc1

at 4:32 PM James Jones wrote: Still testing. I'll get a Sign-off version out this week unless I find a problem. Thanks, -James On 7/12/20 6:37 PM, Dave Airlie wrote: How are we going with a fix for this regression I can commit? Dave. ___ dri-devel

[PATCH v4] drm/nouveau: Accept 'legacy' format modifiers

from Ubuntu 18.04, and sway 1.5 Reported-by: Kirill A. Shutemov Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers") Link: https://lkml.org/lkml/2020/6/30/1251 Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_display.c | 27 +-- 1 fi

Re: [PATCH v3] drm/nouveau: Accept 'legacy' format modifiers

On 7/30/20 3:19 PM, Kirill A. Shutemov wrote: On Thu, Jul 30, 2020 at 10:26:17AM -0700, James Jones wrote: Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Existing Mesa drivers are still aware of only these older

Re: [Nouveau] [PATCH v2] drm/nouveau: Accept 'legacy' format modifiers

On 7/29/20 7:47 AM, Kirill A. Shutemov wrote: On Wed, Jul 29, 2020 at 01:40:13PM +1000, Ben Skeggs wrote: On Wed, 29 Jul 2020 at 12:48, Dave Airlie wrote: On Tue, 28 Jul 2020 at 04:51, James Jones wrote: On 7/23/20 9:06 PM, Ben Skeggs wrote: On Sat, 18 Jul 2020 at 13:34, James Jones

[PATCH v3] drm/nouveau: Accept 'legacy' format modifiers

from Ubuntu 18.04, kmscube hacked to use linear mod, and sway 1.5 Reported-by: Kirill A. Shutemov Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers") Link: https://lkml.org/lkml/2020/6/30/1251 Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_

Re: [Nouveau] [PATCH v2] drm/nouveau: Accept 'legacy' format modifiers

On 7/23/20 9:06 PM, Ben Skeggs wrote: On Sat, 18 Jul 2020 at 13:34, James Jones wrote: Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Existing Mesa drivers are still aware of only these older format modifiers

Re: [Nouveau] [PATCH] drm/nouveau: Accept 'legacy' format modifiers

tree if you weren't already. I was testing with drm-fixes-2020-07-17-1 from here: git://anongit.freedesktop.org/drm/drm Thanks, -James On 7/17/20 8:13 PM, James Jones wrote: This doesn't look related. -James On 7/17/20 2:30 PM, Kirill A. Shutemov wrote: On Fri, Jul 17, 2020 at 11:57:57AM

Re: [PATCH] drm/nouveau: Accept 'legacy' format modifiers

On 7/17/20 12:47 PM, Daniel Vetter wrote: On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote: Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Tested with Xorg 1.20 modesetting driver, weston

[PATCH v2] drm/nouveau: Accept 'legacy' format modifiers

from Ubuntu 18.04, and sway 1.5 Reported-by: Kirill A. Shutemov Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers") Link: https://lkml.org/lkml/2020/6/30/1251 Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_display.c | 26 +-- 1 fi

Re: [PATCH] drm/nouveau: Accept 'legacy' format modifiers

This doesn't look related. -James On 7/17/20 2:30 PM, Kirill A. Shutemov wrote: On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote: Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Tested with Xorg 1.20

Re: [PATCH] drm/nouveau: Accept 'legacy' format modifiers

. Thanks, -James On 7/17/20 11:57 AM, James Jones wrote: Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Tested with Xorg 1.20 modesetting driver, weston@c46c70dac84a4b3030cd05b380f9f410536690fc, gnome & KDE way

[PATCH] drm/nouveau: Accept 'legacy' format modifiers

-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_display.c | 26 +-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 496c4621cc78..31543086254b 100644 --- a/drivers

Re: [git pull] drm for 5.8-rc1

Still testing. I'll get a Sign-off version out this week unless I find a problem. Thanks, -James On 7/12/20 6:37 PM, Dave Airlie wrote: How are we going with a fix for this regression I can commit? Dave. ___ dri-devel mailing list

Re: [git pull] drm for 5.8-rc1

On 7/2/20 2:14 PM, James Jones wrote: On 7/2/20 1:22 AM, Daniel Stone wrote: Hi, On Wed, 1 Jul 2020 at 20:45, James Jones wrote: OK, I think I see what's going on.  In the Xorg modesetting driver, the logic is basically: if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFI

Re: [git pull] drm for 5.8-rc1

On 7/2/20 1:22 AM, Daniel Stone wrote: Hi, On Wed, 1 Jul 2020 at 20:45, James Jones wrote: OK, I think I see what's going on. In the Xorg modesetting driver, the logic is basically: if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS != 0) { drmModeAddFB2WithM

Re: [git pull] drm for 5.8-rc1

dn't look too closely at things beyond that. Thanks, -James On 7/1/20 12:59 AM, Kirill A. Shutemov wrote: On Wed, Jul 01, 2020 at 10:57:19AM +0300, Kirill A. Shutemov wrote: On Tue, Jun 30, 2020 at 09:40:19PM -0700, James Jones wrote: This implies something is trying to use one of the old DR

Re: [git pull] drm for 5.8-rc1

On 7/1/20 10:04 AM, Karol Herbst wrote: On Wed, Jul 1, 2020 at 6:01 PM Daniel Vetter wrote: On Wed, Jul 1, 2020 at 5:51 PM James Jones wrote: On 7/1/20 4:24 AM, Karol Herbst wrote: On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: This implies something is trying to use one of the old

Re: [git pull] drm for 5.8-rc1

On 7/1/20 4:24 AM, Karol Herbst wrote: On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: This implies something is trying to use one of the old DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without first checking whether it is supported by the kernel. I had tried to force

Re: [git pull] drm for 5.8-rc1

of Mesa? Any distro patches? Any non-default xorg.conf options that would affect modesetting, your X driver if it isn't modesetting, or glamour? Thanks, -James On 6/30/20 4:08 PM, Kirill A. Shutemov wrote: On Tue, Jun 02, 2020 at 04:06:32PM +1000, Dave Airlie wrote: James Jones (4

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

On 2/10/20 3:35 PM, Ben Skeggs wrote: On Tue, 11 Feb 2020 at 09:17, James Jones wrote: On 2/10/20 12:25 AM, Thomas Zimmermann wrote: Hi Am 10.02.20 um 09:20 schrieb Ben Skeggs: On Sat, 8 Feb 2020 at 07:10, James Jones wrote: I've sent out a v4 version of the format modifier patches

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

On 2/10/20 12:25 AM, Thomas Zimmermann wrote: Hi Am 10.02.20 um 09:20 schrieb Ben Skeggs: On Sat, 8 Feb 2020 at 07:10, James Jones wrote: I've sent out a v4 version of the format modifier patches which avoid caching values in the nouveau_framebuffer struct. It will have a few trivial

[PATCH v5 3/3] drm/nouveau: Support NVIDIA format modifiers

display hardware. v2: Used Tesla family instead of NV50 chipset compare v4: Do not cache kind, tile_mode in nouveau_framebuffer v5: Resolved against nouveau_framebuffer cleanup Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 20 +++-- drivers/gpu/drm/nouveau

[PATCH v5 2/3] drm/nouveau: Check framebuffer size against bo

Make sure framebuffer dimensions and tiling parameters will not result in accesses beyond the end of the GEM buffer they are bound to. v3: Return EINVAL when creating FB against BO with unsupported tiling v5: Resolved against nouveau_framebuffer cleanup Signed-off-by: James Jones

[PATCH v5 0/3] drm/nouveau: Support NVIDIA format modifiers

ed against nouveau_framebuffer cleanup James Jones (3): drm/nouveau: Add format mod prop to base/ovly/nvdisp drm/nouveau: Check framebuffer size against bo drm/nouveau: Support NVIDIA format modifiers drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +- drivers/gpu/drm/nouveau/dispnv50/disp.c

[PATCH v5 1/3] drm/nouveau: Add format mod prop to base/ovly/nvdisp

. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 + drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +- drivers/gpu/drm/nouveau/dispnv50

[PATCH] drm/nouveau: Fix NULL ptr access in nv50_wndw_prepare_fb()

ned-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c b/drivers/gpu/drm/nouveau/dispnv50/wndw.c index 4a67a656e007..68c0dc2dc2d3 100644 --- a/drivers/gpu/drm/nouveau/dispn

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

, but if these cleanup patches are taken, only v4 will work. Thanks, -James On 2/6/20 8:45 AM, James Jones wrote: Yes, that's certainly viable.  If that's the general preference in direction, I'll rework that patches to do so. Thanks, -James On 2/6/20 7:49 AM, Thomas Zimmermann wrote: Hi James Am 06.02.20

[PATCH v4 2/3] drm/nouveau: Check framebuffer size against bo

Make sure framebuffer dimensions and tiling parameters will not result in accesses beyond the end of the GEM buffer they are bound to. v3: Return EINVAL when creating FB against BO with unsupported tiling Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_display.c | 97

[PATCH v4 1/3] drm/nouveau: Add format mod prop to base/ovly/nvdisp

. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 + drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +- drivers/gpu/drm/nouveau/dispnv50

[PATCH v4 0/3] drm/nouveau: Support NVIDIA format modifiers

sting code. v3: -Rebased on nouveau linux-5.6 @ 137c4ba7163ad9d5696b9fde78b1c0898a9c115b -Noted corresponding Mesa patches are production-worthy now -Better validate bo tile_mode when checking framebuffer size. v4: Do not cache kind, tile_mode in nouveau_framebuffer James Jones (3): drm/no

[PATCH v4 3/3] drm/nouveau: Support NVIDIA format modifiers

display hardware. v2: Used Tesla family instead of NV50 chipset compare v4: Do not cache kind, tile_mode in nouveau_framebuffer Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 18 +++-- drivers/gpu/drm/nouveau/nouveau_display.c | 90 ++- drivers/gpu/drm

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

Yes, that's certainly viable. If that's the general preference in direction, I'll rework that patches to do so. Thanks, -James On 2/6/20 7:49 AM, Thomas Zimmermann wrote: Hi James Am 06.02.20 um 16:17 schrieb James Jones: Note I'm adding some fields to nouveau_framebuffer in the series

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

Yes, that's certainly viable. If that's the general preference in direction, I'll rework that patches to do so. Thanks, -James On 2/6/20 7:49 AM, Thomas Zimmermann wrote: Hi James Am 06.02.20 um 16:17 schrieb James Jones: Note I'm adding some fields to nouveau_framebuffer in the series

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

Note I'm adding some fields to nouveau_framebuffer in the series "drm/nouveau: Support NVIDIA format modifiers." I sent out v3 of that yesterday. It would probably still be possible to avoid them by re-extracting the relevant data from the format modifier on the fly when needed, but it is

Re: [Nouveau] [PATCH v2 0/3] drm/nouveau: Support NVIDIA format modifiers

On 1/6/20 3:27 PM, Ben Skeggs wrote: On Tue, 7 Jan 2020 at 05:17, James Jones wrote: On 1/5/20 5:30 PM, Ben Skeggs wrote: On Tue, 17 Dec 2019 at 10:44, James Jones wrote: This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display

[PATCH v3 3/3] drm/nouveau: Support NVIDIA format modifiers

hardware. v2: Used Tesla family instead of NV50 chipset compare Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 8 +-- drivers/gpu/drm/nouveau/nouveau_display.c | 65 ++- drivers/gpu/drm/nouveau/nouveau_display.h | 2 + 3 files changed, 69

[PATCH v3 0/3] drm/nouveau: Support NVIDIA format modifiers

: -Rebased on nouveau linux-5.6 @ 137c4ba7163ad9d5696b9fde78b1c0898a9c115b -Noted corresponding Mesa patches are production-worthy now -Better validate bo tile_mode when checking framebuffer size. James Jones (3): drm/nouveau: Add format mod prop to base/ovly/nvdisp drm/nouveau: Check frameb

[PATCH v3 2/3] drm/nouveau: Check framebuffer size against bo

Make sure framebuffer dimensions and tiling parameters will not result in accesses beyond the end of the GEM buffer they are bound to. v3: Return EINVAL when creating FB against BO with unsupported tiling Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_display.c | 97

[PATCH v3 1/3] drm/nouveau: Add format mod prop to base/ovly/nvdisp

. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 + drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +- drivers/gpu/drm/nouveau/dispnv50

Re: [Nouveau] [PATCH v2 0/3] drm/nouveau: Support NVIDIA format modifiers

On 1/5/20 5:30 PM, Ben Skeggs wrote: On Tue, 17 Dec 2019 at 10:44, James Jones wrote: This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace

Re: [Nouveau] [PATCH v2 2/3] drm/nouveau: Check framebuffer size against bo

On 1/5/20 5:25 PM, Ben Skeggs wrote: On Tue, 17 Dec 2019 at 10:45, James Jones wrote: Make sure framebuffer dimensions and tiling parameters will not result in accesses beyond the end of the GEM buffer they are bound to. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau

[PATCH] drm/nouveau: Add correct turing page kinds

r, because that will be a rather invasive change to nouveau and 0x00 still works fine in practice on Turing hardware, addressing this new behavior is deferred. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/include/nvif/if0008.h| 2 +- drivers/gpu/drm/nouveau/include/nvif/mmu.h | 4 ++-

[PATCH] drm/nouveau: Fix ttm move init with multiple GPUs

-static to fix the logic. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_bo.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index f8015e0318d7..1b62ccc57aef 100644 --- a/drivers

[PATCH] drm/tegra: Use more descriptive format modifiers

dri-devel. Signed-off-by: James Jones --- drivers/gpu/drm/tegra/dc.c | 10 ++ drivers/gpu/drm/tegra/fb.c | 14 +++--- drivers/gpu/drm/tegra/hub.c | 10 ++ 3 files changed, 27 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/

Re: [Nouveau] [PATCH 3/3] drm/nouveau: Support NVIDIA format modifiers

On 12/12/19 6:51 PM, James Jones wrote: On 12/11/19 1:13 PM, Ilia Mirkin wrote: On Wed, Dec 11, 2019 at 4:04 PM James Jones wrote: Allow setting the block layout of a nouveau FB object using DRM format modifiers.  When specified, the format modifier block layout and kind overrides the GEM

[PATCH v2 2/3] drm/nouveau: Check framebuffer size against bo

Make sure framebuffer dimensions and tiling parameters will not result in accesses beyond the end of the GEM buffer they are bound to. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_display.c | 93 +++ 1 file changed, 93 insertions(+) diff --git a/drivers

[PATCH v2 0/3] drm/nouveau: Support NVIDIA format modifiers

, and left as-is for consistency with existing code. James Jones (3): drm/nouveau: Add format mod prop to base/ovly/nvdisp drm/nouveau: Check framebuffer size against bo drm/nouveau: Support NVIDIA format modifiers drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +- drivers/gpu/drm/nouveau/dispn

[PATCH v2 3/3] drm/nouveau: Support NVIDIA format modifiers

hardware. v2: Used Tesla family instead of NV50 chipset compare Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 8 +-- drivers/gpu/drm/nouveau/nouveau_display.c | 65 ++- drivers/gpu/drm/nouveau/nouveau_display.h | 2 + 3 files changed, 69

[PATCH v2 1/3] drm/nouveau: Add format mod prop to base/ovly/nvdisp

. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 + drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +- drivers/gpu/drm/nouveau/dispnv50

Re: [Nouveau] [PATCH 3/3] drm/nouveau: Support NVIDIA format modifiers

On 12/11/19 1:13 PM, Ilia Mirkin wrote: On Wed, Dec 11, 2019 at 4:04 PM James Jones wrote: Allow setting the block layout of a nouveau FB object using DRM format modifiers. When specified, the format modifier block layout and kind overrides the GEM buffer's implicit layout and kind

[PATCH 3/3] drm/nouveau: Support NVIDIA format modifiers

hardware. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 8 +-- drivers/gpu/drm/nouveau/nouveau_display.c | 65 ++- drivers/gpu/drm/nouveau/nouveau_display.h | 2 + 3 files changed, 69 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm

[PATCH 2/3] drm/nouveau: Check framebuffer size against bo

Make sure framebuffer dimensions and tiling parameters will not result in accesses beyond the end of the GEM buffer they are bound to. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/nouveau_display.c | 93 +++ 1 file changed, 93 insertions(+) diff --git a/drivers

[PATCH 0/3] drm/nouveau: Support NVIDIA format modifiers

Block Linear DRM format mod" patch submitted to dri-devel. Signed-off-by: James Jones --- drivers/gpu/drm/tegra/dc.c | 10 ++ drivers/gpu/drm/tegra/fb.c | 14 +++--- drivers/gpu/drm/tegra/hub.c | 10 ++ 3 files changed, 27 insertions(+), 7 deletions(-) diff --git a/d

[PATCH 1/3] drm/nouveau: Add format mod prop to base/ovly/nvdisp

. Signed-off-by: James Jones --- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 7 +-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 + drivers/gpu/drm/nouveau/dispnv50/disp.h | 4 ++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 27 +- drivers/gpu/drm/nouveau/dispnv50

Re: [PATCH 0/3] drm/nouveau: Support NVIDIA format modifiers

Please ignore the tegra diff on the bottom of this. I never fail to find a way to mess up git-send-email. -James On 12/11/19 12:59 PM, James Jones wrote: This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode

[PATCH v3] drm: Generalized NV Block Linear DRM format mod

v3: - Added additional bit to compression field to support Tesla (NV5x,G8x,G9x,GT1xx,GT2xx) class chips. Signed-off-by: James Jones --- include/uapi/drm/drm_fourcc.h | 122 +++--- 1 file changed, 114 insertions(+), 8 deletions(-) diff --git a/include/uapi/drm/d

Re: [PATCH] drm: Generalized NV Block Linear DRM format mod

On 10/15/19 8:42 AM, Daniel Vetter wrote: On Tue, Oct 15, 2019 at 5:14 PM James Jones wrote: On 10/15/19 7:19 AM, Daniel Vetter wrote: On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote: Builds upon the existing NVIDIA 16Bx2 block linear format modifiers by adding more "f

[PATCH v2] drm: Generalized NV Block Linear DRM format mod

nto nouveau userspace drivers with modifiers in Mesa. Hence it is assumed the prior modifiers were not intended for use on desktop GPUs, and as a corrolary, were not intended to support sharing block linear buffers across two different NVIDIA GPUs. v2: - Added canonicalize helper function Signed-off

Re: [PATCH] drm: Generalized NV Block Linear DRM format mod

On 10/15/19 7:19 AM, Daniel Vetter wrote: On Mon, Oct 14, 2019 at 03:13:21PM -0700, James Jones wrote: Builds upon the existing NVIDIA 16Bx2 block linear format modifiers by adding more "fields" to the existing parameterized DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier macro

[PATCH] drm: Generalized NV Block Linear DRM format mod

Beyond general review, I'm looking for feedback on a few things specifically here: -Is the level of backwards compatibility described here sufficient? Technically I can make the user space drivers support the old modifiers too, but that would mean the layout they specify would morph based on

[PATCH] drm: Generalized NV Block Linear DRM format mod

nto nouveau userspace drivers with modifiers in Mesa. Hence it is assumed the prior modifiers were not intended for use on desktop GPUs, and as a corrolary, were not intended to support sharing block linear buffers across two different NVIDIA GPUs. Signed-off-by: James Jones --- inclu

Re: XDC allocator workshop and Wayland dmabuf hints

On 10/13/19 2:05 PM, Scott Anderson wrote: (Sorry to CCs for spam, I made an error in my first posting) Hi, There were certainly some interesting changes discussed at the allocator workshop during XDC this year, and I'd like to just summarise my thoughts on it and make sure everybody is on the

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

On 02/22/2018 01:16 PM, Alex Deucher wrote: On Thu, Feb 22, 2018 at 1:49 PM, Bas Nieuwenhuizen wrote: On Thu, Feb 22, 2018 at 7:04 PM, Kristian Høgsberg wrote: On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher wrote: On Wed,

Re: [Mesa-dev] Allocator Nouveau driver, Mesa EXT_external_objects, and DRM metadata import interfaces

On 12/28/2017 10:24 AM, Miguel Angel Vico wrote: (Adding dri-devel back, and trying to respond to some comments from the different forks) James Jones wrote: Your worst case analysis above isn't far off from our HW, give or take some bits and axes here and there. We've started an internal

Re: [rfc repost] drm sync objects - a new beginning (make ickle happier?)

On 04/19/2017 05:07 AM, Christian König wrote: Am 13.04.2017 um 03:41 schrieb Dave Airlie: Okay I've taken Chris's suggestions to heart and reworked things around a sem_file to see how they might look. This means the drm_syncobj are currently only useful for semaphores, the flags field could

Re: Static inline DRM functions calling into GPL-only code

On 04/11/2017 09:09 AM, Harry Wentland wrote: On 2017-04-11 11:15 AM, James Jones wrote: On 04/10/2017 11:20 PM, Daniel Vetter wrote: On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter <dan...@ffwll.ch> wrote: On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale <nmah...@nvidia.com> wro

Re: Static inline DRM functions calling into GPL-only code

On 04/10/2017 11:20 PM, Daniel Vetter wrote: On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter wrote: On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale wrote: My name is Nikhil Mahale, and I work at NVIDIA in the Linux drivers team. I have been working on

Re: Vulkan WSI+VK_KHR_display for KMS/DRM?

On 04/10/2017 12:32 PM, Jason Ekstrand wrote: On April 10, 2017 12:29:12 PM Chad Versace wrote: On Tue 04 Apr 2017, Keith Packard wrote: Jason Ekstrand writes: > Interesting question. To my knowledge, no one has actually implemented the >

Unix Device Memory Allocation project

On 01/03/2017 04:06 PM, Marek Olšák wrote: > On Wed, Jan 4, 2017 at 12:43 AM, James Jones wrote: >> On 01/03/2017 03:38 PM, Marek Olšák wrote: >>> >>> On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter wrote: >>>> >>>> On Wed, Oct 19, 2016 at 6

Unix Device Memory Allocation project

On 01/03/2017 03:38 PM, Marek Olšák wrote: > On Thu, Oct 20, 2016 at 8:31 AM, Daniel Vetter wrote: >> On Wed, Oct 19, 2016 at 6:46 PM, Marek Olšák wrote: > We've had per buffer metadata in Radeon since KMS, which I believe first > appeared in 2009. It's 4 bytes large and is used to

Unix Device Memory Allocation project

esn't give us any other flags, so we are stuck with those. > - Inter-device sharing is possible if the consumer understands the > producer's metadata and tiling layouts. > > (amdgpu actually stores 2 different metadata blocks per allocation, > but the simpler one is too limited and ha

Unix Device Memory Allocation project

Hello everyone, As many are aware, we took up the issue of surface/memory allocation at XDC this year. The outcome of that discussion was the beginnings of a design proposal for a library that would server as a cross-device, cross-process surface allocator. In the past week I've started to

[RFC] Explicit synchronization for Nouveau

On 9/29/14 8:42 AM, Jerome Glisse wrote: > On Mon, Sep 29, 2014 at 09:43:02AM +0200, Daniel Vetter wrote: >> On Fri, Sep 26, 2014 at 01:00:05PM +0300, Lauri Peltonen wrote: >>> >>> Hi guys, >>> >>> >>> I'd like to start a new thread about explicit fence synchronization. This >>> time >>> with a