On Fri, 28 Mar 2025 at 21:12, Danilo Krummrich <[email protected]> wrote: > > On Thu, Mar 27, 2025 at 02:26:09PM -0400, M Henning wrote: > > On Thu, Mar 27, 2025 at 8:56 AM Danilo Krummrich <[email protected]> wrote: > > > > > > 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. > > > > Well, NV2080_CTRL_GR_GET_ZCULL_INFO_PARAMS is r535-specific, but we > > need to convert it into a common structure and combine it with info > > from NV0080_CTRL_FIFO_GET_ENGINE_CONTEXT_PROPERTIES at some point, so > > I think it makes sense to do that conversion+combination before > > storing it on any structure. In that case, maybe we store the > > structure on nvkm_gr directly during r535_gr_oneinit and then the call > > to get the info only goes through NVIF? > > Sounds good to me! It means you need an intermediate structure though, we > should > avoid using uAPI structures in NVKM code.
I don't think we need to go through NVIF, or at least we could do it, but there is no gr object exposed through it now and adding a whole load of gr code to nvif would be a nightmare, I'd rather we merged the kill nvif patches. I think not using the uapi struct in nvkm is all we need to maintain, nvkm has it's structure, uapi has it's structure and we just pass between them. nvkm_gr_units already exists as an nvif bypass so I think it's probably fine. Dave.
