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
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.
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
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
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
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
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/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
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 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/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
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/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
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 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
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.
___
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
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,
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/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
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/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
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
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
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,
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
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
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 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 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/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 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
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 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
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
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
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
.
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
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
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
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
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
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
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
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
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
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
.
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
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 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
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 ++-
-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
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/
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
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
, 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
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
.
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
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.
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
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
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
.
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
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
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
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
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 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
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
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
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
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 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 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/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/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 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
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
)
> - 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
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
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
91 matches
Mail list logo
