All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: M Henning <mhenning@darkrefraction.com>
Cc: Ben Skeggs <bskeggs@nvidia.com>,
	Karol Herbst <kherbst@redhat.com>, Lyude Paul <lyude@redhat.com>,
	Faith Ekstrand <faith.ekstrand@collabora.com>,
	dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/nouveau: Add DRM_IOCTL_NOUVEAU_GET_ZCULL_INFO
Date: Thu, 27 Mar 2025 13:56:17 +0100	[thread overview]
Message-ID: <Z-VK8eeA_7BURiBy@cassiopeiae> (raw)
In-Reply-To: <CAAgWFh1VzRnt9QdCR9xOVhar7vEYAGPBcMHfqXGq_QHm0A6H8Q@mail.gmail.com>

On Tue, Mar 25, 2025 at 07:40:56PM -0400, M Henning wrote:
> Okay, that sounds reasonable since I don't expect this to change very quickly.
> 
> Since I don't fully understand, is the suggestion here to:
> 1) add the interface as a function on nvkm_gr using the nvkm_gr_func
> vtable and store the actual data on r535_gr
> or
> 2) add the interface to NVIF (which IF?) and store the actual data on nvkm_gr
> ?

I think we want both.

1) I think the suggestion was to store the data directly in nvkm_gr, however the
   structure is indeed specific to r535, so I think, unfortunately, we need the
   vtable and store that data in r535_gr.

2) Yes, this should be passed through nvif. Unfortunately, I think it would need
   to be a whole new one (similar to the fifo one).

Maybe Ben can provide you some additional pointers one this? Mayber he can
suggest a shortcut, since he has patches queued to simplify the whole interface.

> 
> (Sorry, I don't understand how these layers are intended to fit together.))
> 
> On Thu, Mar 20, 2025 at 4:02 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >
> > On Fri, Mar 21, 2025 at 05:57:55AM +1000, Ben Skeggs wrote:
> > > On 21/3/25 04:18, Danilo Krummrich wrote:
> > >
> > > > Hi Mel,
> > > >
> > > > On Wed, Mar 12, 2025 at 05:36:14PM -0400, Mel Henning wrote:
> > >
> > > > > @@ -72,6 +75,9 @@ struct nvkm_device {
> > > > >                   bool armed;
> > > > >                   bool legacy_done;
> > > > >           } intr;
> > > > > +
> > > > > + bool has_zcull_info;
> > > > > + struct drm_nouveau_get_zcull_info zcull_info;
> > > > This is bypassing the nvif layer entirely. I think you should store the contents
> > > > of struct NV2080_CTRL_GR_GET_ZCULL_INFO_PARAMS in struct r535_gr and have an
> > > > nvif interface to access the data.
> > >
> > > I agree here, though nvkm_gr would be a better choice for a couple of
> > > reasons, not least that it's possible (and should be reasonably trivial) to
> > > support this on earlier GPUs - should someone desire to at a later point.
> >
> > I agree, if the interface is stable enough -- I don't know whether this is prone
> > to change or not.

  reply	other threads:[~2025-03-27 12:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-12 21:36 [PATCH 0/2] drm/nouveau: ZCULL support Mel Henning
2025-03-12 21:36 ` [PATCH 1/2] drm/nouveau: Add DRM_IOCTL_NOUVEAU_GET_ZCULL_INFO Mel Henning
2025-03-20 18:18   ` Danilo Krummrich
2025-03-20 18:37     ` Danilo Krummrich
2025-03-20 19:57     ` Ben Skeggs
2025-03-20 20:01       ` Danilo Krummrich
2025-03-25 23:40         ` M Henning
2025-03-27 12:56           ` Danilo Krummrich [this message]
2025-03-27 18:26             ` M Henning
2025-03-28 11:04               ` Danilo Krummrich
2026-02-05  0:43                 ` Dave Airlie
2026-02-05  0:43                   ` Dave Airlie
2026-02-05 10:58                   ` Danilo Krummrich
2026-02-05 10:58                     ` Danilo Krummrich
2025-03-21 22:06     ` M Henning
2025-03-27 13:51       ` Danilo Krummrich
2025-03-27 18:03         ` M Henning
2025-03-28 11:09           ` Danilo Krummrich
2026-02-05  1:16             ` Dave Airlie
2026-02-05  1:16               ` Dave Airlie
2026-02-05  2:13               ` John Hubbard
2026-02-05  2:13                 ` John Hubbard
2026-02-05 10:46               ` Danilo Krummrich
2026-02-05 10:46                 ` Danilo Krummrich
2025-03-12 21:36 ` [PATCH 2/2] drm/nouveau: DRM_NOUVEAU_SET_ZCULL_CTXSW_BUFFER Mel Henning
2025-03-20 18:34   ` Danilo Krummrich
2025-03-21 23:00     ` M Henning
2025-03-27 13:58       ` Danilo Krummrich
2025-03-27 19:01         ` M Henning
2025-03-28 11:48           ` Danilo Krummrich
2025-08-01  2:15             ` M Henning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z-VK8eeA_7BURiBy@cassiopeiae \
    --to=dakr@kernel.org \
    --cc=bskeggs@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=faith.ekstrand@collabora.com \
    --cc=kherbst@redhat.com \
    --cc=lyude@redhat.com \
    --cc=mhenning@darkrefraction.com \
    --cc=nouveau@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.