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/nouvea
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 modifier
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 diffe
3:
- 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
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
.
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
alized NV 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
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
splay 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/gp
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.
.
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
splay 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 change
, 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/nou
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
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
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/
-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
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 ++-
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
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 are
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
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
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 th
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
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
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 "field
arget 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/gp
h existing 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):
d
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
.
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
t 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 wrot
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
.
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
esolved 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/d
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
arget 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/no
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
tr
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 pa
.
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
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
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.
James Jones (3):
drm/nouveau: Add format mod prop to base/ovly/nvdisp
drm/nouveau: Check f
splay 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 change
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
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 sim
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_frame
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_frame
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
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
Again, 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 o
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
c
)
> - Possible flags: READ, WRITE, READ+WRITE
> - OpenCL doesn'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 met
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
> Vulkan WSI direct-to-display extensions. (I tried
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 adding DRM KMS support to our driver. The
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 wrote:
On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale
wrote:
My name is Nikhil Mahale, and I work at NVIDIA
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 be
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 co
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
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
dri-devel@lists
f-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
e appropriate
lists.
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,
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
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
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
x27;s 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, 202
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
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_
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
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
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
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 Jon
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
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
on just
testing the forcibly-disabled atomic path in the modesetting driver in
this build, so I didn'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
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) {
drmModeAddFB2
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_M
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 will
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
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 Aug
er
devices..
Thanks
On Tue, Jul 14, 2020 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.
___
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 as
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
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
ase you all were wondering, it works on xorg-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 cod
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 Contiguou
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 N
Right, there are 3 iterations of block linear tiling actually. NV50 does
support scanout of block linear surfaces. All block-linear-capable GPUs
do. The 3 generations are:
NV5x/G8x/GTXXX line: Original block size.
GFXXX(nvc0 I believe in nouveau terms)-GV100: double the block height I
believe.
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, Feb 21, 2018 at 1:14 AM, Chad Versace
wrote:
On Thu 21 Dec 2017, Da
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 a
On 1/20/25 14:00, Laurent Pinchart wrote:
On Fri, Jan 10, 2025 at 01:23:40PM -0800, James Jones wrote:
On 12/19/24 10:03, Simona Vetter wrote:
On Thu, Dec 19, 2024 at 09:02:27AM +, Daniel Stone wrote:
On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
On Wed, Dec 18, 2024 at 11:24:58AM
ng only 1 linear
modifier is OK. Then, you can look at modifiers of other drivers if you
want to find commonalities.
DRM_FORMAT_MOD_LINEAR needs to go because it prevents apps from
detecting whether 2 devices have 0 compatible memory layouts, which is a
useful thing to know.
Marek
On Fri, Jan 10
On 12/19/24 10:03, Simona Vetter wrote:
On Thu, Dec 19, 2024 at 09:02:27AM +, Daniel Stone wrote:
On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
For that reason I think linear modifiers with explicit pitch/size
alignment c
On 7/3/25 16:22, Faith Ekstrand wrote:
On Thu, Jul 3, 2025 at 6:34 PM James Jones <mailto:jajo...@nvidia.com>> wrote:
The layout of bits within the individual tiles
(referred to as sectors in the
DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro)
changed for some formats st
eter twice. However, I believe the added helper functions
and macros address the complexity, and I have audited the relevant
code and do not believe the double evaluation should cause any
problems in practice.
James Jones (4):
drm: macros defining fields of NVIDIA modifiers
drm: add inline helper
nouveau driver.
This change adds macros defining the mask and
bit shift associated with each parameteric field
in these modifiers.
Signed-off-by: James Jones
---
include/uapi/drm/drm_fourcc.h | 38 ++-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a
nouveau driver.
This change adds macros using the previously added
field definition macros to extract values from
individual fields in a valid NVIDIA block-linear
format modifier.
Signed-off-by: James Jones
---
include/uapi/drm/drm_fourcc.h | 44 ---
1 file changed
-by: James Jones
---
drivers/gpu/drm/nouveau/nouveau_display.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index add006fc8d81..1bec664a2b67 100644
--- a/drivers/gpu/drm/nouveau
pear to be problematic in any current
usage, but I thought it was worth calling out.
Signed-off-by: James Jones
---
include/uapi/drm/drm_fourcc.h | 46 +--
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/includ
On 7/4/25 07:45, Faith Ekstrand wrote:
On Thu, Jul 3, 2025 at 6:34 PM James Jones <mailto:jajo...@nvidia.com>> wrote:
The layout of bits within the individual tiles (referred to as
sectors in the DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro)
changed for some formats st
: 41ab92d35ccd ("drm: Make passing of format info to
drm_helper_mode_fill_fb_struct() mandatory")
Signed-off-by: James Jones
CC: Ville Syrjälä
---
drivers/gpu/drm/nouveau/nouveau_display.c | 9 +++--
drivers/gpu/drm/nouveau/nouveau_display.h | 1 +
2 files changed, 4 insert
Review-by: James Jones
Tested-by: James Jones
Tested on GB203, TU102, and NV50.
Thanks,
-James
On 7/28/25 03:16, Imre Deak wrote:
Plumb the format info from .fb_create() all the way to
drm_helper_mode_fill_fb_struct() to avoid the redundant
lookup.
The patch is based on the driver parts of
1 - 100 of 101 matches
Mail list logo
