similar to: [PATCH v3 0/2] drm/nouveau: Add drm_panic support for nv50+

On Fri, 2024-09-13 at 09:03 +0200, Jocelyn Falempe wrote: > Add drm_panic support, for nv50+ cards. > It's enough to get the panic screen while running Gnome/Wayland on a > GTX 1650. > It doesn't support multi-plane or compressed format. > Support for other formats and older cards will come later. > Tiling is only tested on GTX1650, and might be wrong for other cards.

Add drm_panic support, for nv50+ cards. It's enough to get the panic screen while running Gnome/Wayland on a GTX 1650. It doesn't support multi-plane or compressed format. Support for other formats and older cards will come later. Tiling is only tested on GTX1650, and might be wrong for other cards. Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com> --- v2: * Rebase and drop

On 18/10/2024 23:50, Lyude Paul wrote: > On Fri, 2024-09-13 at 09:03 +0200, Jocelyn Falempe wrote: >> Add drm_panic support, for nv50+ cards. >> It's enough to get the panic screen while running Gnome/Wayland on a >> GTX 1650. >> It doesn't support multi-plane or compressed format. >> Support for other formats and older cards will come later. >>

This series adds basic drm_panic support for nouveau. Patches 1-2 Add missing bits in drm_panic (ABGR2101010, private data for set_pixel()) Patch 3 registers nouveau to drm_panic, and handle tiling. I've tested on a GTX1650, while running Gnome/Wayland desktop. It should work on other nv50+ cards, but I didn't test them. To test it, you need to build your kernel with CONFIG_DRM_PANIC=y,

Hi Jocelyn, kernel test robot noticed the following build warnings: [auto build test WARNING on 484436ec5c2bffe8f346a09ae1cbc4cbf5e50005] url: https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-panic-Add-ABGR2101010-support/20240523-211335 base: 484436ec5c2bffe8f346a09ae1cbc4cbf5e50005 patch link: https://lore.kernel.org/r/20240523130955.428233-6-jfalempe%40redhat.com

On 13/09/2024 09:22, Javier Martinez Canillas wrote: > Jocelyn Falempe <jfalempe at redhat.com> writes: > > Hello Jocelyn, > >> Add support for ABGR2101010, used by the nouveau driver. >> >> Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com> >> --- >> drivers/gpu/drm/drm_panic.c | 10 ++++++++++ >> 1 file changed, 10

Jocelyn Falempe <jfalempe at redhat.com> writes: Hello Jocelyn, > Add support for ABGR2101010, used by the nouveau driver. > > Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com> > --- > drivers/gpu/drm/drm_panic.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c > index

Add support for ABGR2101010, used by the nouveau driver. Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com> --- drivers/gpu/drm/drm_panic.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c index 74412b7bf936..0a9ecc1380d2 100644 --- a/drivers/gpu/drm/drm_panic.c +++ b/drivers/gpu/drm/drm_panic.c @@ -209,6 +209,14

On Wed, Sep 11, 2024 at 10:19?AM Jocelyn Falempe <jfalempe at redhat.com> wrote: > On 06/09/2024 21:36, James Jones wrote: > > 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.

This patch series introduces the VHD library. It is based on the blktap2 one, with changes coming from the blktap2.5 one. Signed-off-by: Thanos Makatos <thanos.makatos@citrix.com>

The 'w' argument to NVCopyNV12ColorPlanes is used to index into the source image. line_len is rounded up to 8 on NV50+, so if the source image (+ left offset) is not rounded to 8, NVCopyNV12ColorPlanes could read past the end of the array and crash X. This change can cause the last few horizontal pixels of dst to not be initialized, but they should be truncated by the renderer anyways.

Many people using nv50+ hardware are aware of gpu lockups when a fifo closes under certain conditions. Based on a mmio-trace and some trail and error testing i've come up with a patch that improves the situation on my NV96. This patch needs testing on NV50+ hardware and regression testing on older hardware, since i did change some of the common codepaths. This is very much a work in progress,

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

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

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 simpler and likely less error-prone with the wrapper struct. Thanks, -James On 2/6/20

This fixes a kernel oops when loading the nouveau module with fb console enabled after the change: drm/nouveau: Remove field nvbo from struct nouveau_framebuffer state->fb may be NULL in nv50_wndw_prepare_fb(), so defer initializing nvbo from its obj[] array until after the NULL check. Signed-off-by: James Jones <jajones at nvidia.com> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 3

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,

All fields in struct nouveau_framebuffer appear to be obsolete. The data structure can be replaced by struct drm_framebuffer entirely. Patch 1 removes several unused fields from struct nouveau_framebuffer. Patch 2 moves the field vma to struct nouveau_fbdev. The information in vma is only relevant for fbdev emulation, and as such he field is only used there. Patch 3 removes nvbo from struct

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,