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

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 that allow fully defining a unique-across- all-NVIDIA-hardware bit layout using a minimal set of fields and values. The new modifier macro DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D is effectively backwards

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 that allow fully defining a unique-across- all-NVIDIA-hardware bit layout using a minimal set of fields and values. The new modifier macro DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D is effectively backwards

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 that allow fully defining a unique-across- >>

On Tue, Oct 15, 2019 at 5:14 PM James Jones <jajones at nvidia.com> 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 "fields" to the > >> existing parameterized > >>

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 that allow fully defining a unique-across- > all-NVIDIA-hardware bit layout using a minimal > set of fields and values.

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 the GPU they're being used on, and sharing buffers between two different NV GPUs, which would

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 available here: https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work But those need a bit of cleanup before they're ready to submit. I've tested this on Tesla, Kepler, Pascal,

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 > setting blobs. > > Corresponding modifications to Mesa/userspace are available

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 at c46c70dac84a4b3030cd05b380f9f410536690fc, >> gnome

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 which do not differentiate between different variations of the block linear layout. When the format modifier support flag was flipped in the nouveau kernel driver, the X.org modesetting driver

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 at c46c70dac84a4b3030cd05b380f9f410536690fc, > gnome & KDE wayland desktops from Ubuntu 18.04, > and sway 1.5 Just

On Sat, 18 Jul 2020 at 13:34, James Jones <jajones at nvidia.com> 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 which do not differentiate > between different variations of the block linear >

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 which do not differentiate between different variations of the block linear layout. When the format modifier support flag was flipped in the nouveau kernel driver, the X.org modesetting driver

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 at c46c70dac84a4b3030cd05b380f9f410536690fc, gnome & KDE wayland desktops from Ubuntu 18.04, and sway 1.5 Signed-off-by: James Jones <jajones at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 26

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 which do not differentiate between different variations of the block linear layout. When the format modifier support flag was flipped in the nouveau kernel driver, the X.org modesetting driver

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 available on the Mesa-dev mailing list as the series: nouveau: Improved format modifier support I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware using various formats

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 available here: https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work But those need a bit of cleanup before they're ready to submit. I've tested this on Tesla, Kepler, Pascal,

On 7/23/20 9:06 PM, Ben Skeggs wrote: > On Sat, 18 Jul 2020 at 13:34, James Jones <jajones at nvidia.com> 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 which do not

Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com> --- include/uapi/drm/drm.h | 16 ++++++++++++++++ include/uapi/drm/drm_fourcc.h | 8 ++++++++ include/uapi/drm/drm_mode.h | 8 ++++++++ include/uapi/drm/drm_sarea.h | 8 ++++++++ 4 files changed, 40 insertions(+) diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 3683250..452675f 100644 ---

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 available on the Mesa-dev gitlab merge request 3724: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3724 I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware using