On Fri, 28 Mar 2025 at 21:09, Danilo Krummrich <[email protected]> wrote: > > (CC: Ben, John) > > On Thu, Mar 27, 2025 at 02:03:21PM -0400, M Henning wrote: > > On Thu, Mar 27, 2025 at 9:51 AM Danilo Krummrich <[email protected]> wrote: > > > > > > On Fri, Mar 21, 2025 at 06:06:34PM -0400, M Henning wrote: > > > > On Thu, Mar 20, 2025 at 2:18 PM Danilo Krummrich <[email protected]> > > > > wrote: > > > > > On Wed, Mar 12, 2025 at 05:36:14PM -0400, Mel Henning wrote: > > > > > > + __u32 width_align_pixels; > > > > > > + __u32 height_align_pixels; > > > > > > + __u32 pixel_squares_by_aliquots; > > > > > > + __u32 aliquot_total; > > > > > > + __u32 zcull_region_byte_multiplier; > > > > > > + __u32 zcull_region_header_size; > > > > > > + __u32 zcull_subregion_header_size; > > > > > > + __u32 subregion_count; > > > > > > + __u32 subregion_width_align_pixels; > > > > > > + __u32 subregion_height_align_pixels; > > > > > > + > > > > > > + __u32 ctxsw_size; > > > > > > + __u32 ctxsw_align; > > > > > > +}; > > > > > > > > > > What if this ever changes between hardware revisions or firmware > > > > > versions? > > > > > > > > There was some previous discussion of that here: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/12596#note_2796853 > > > > > > > > From what I can tell, this structure hasn't really changed since > > > > FERMI_C (circa 2011), so I'm not too worried about it changing on us > > > > too quickly. When it does change, we have the option of appending more > > > > members to this struct in the usual way, or if the change is more > > > > fundamental we can return an error from this ioctl and add a new > > > > interface. Userspace needs to handle an error from this ioctl > > > > gracefully anyway since whether it works or not depends on the gpu > > > > generation and what firmware is loaded right now. > > > > > > We could also define it as > > > > > > struct drm_nouveau_get_zcull_info { > > > __u32 version; > > > __u32 _pad; > > > > > > union { > > > struct drm_nouveau_get_zcull_info_v1 info; > > > } > > > } > > > > > > just to be safe. > > > > We can do that, although I don't see any other drm drivers using a > > similar pattern anywhere. > > I think it's a bit cleaner than adding new members, leave existing ones unset > or > add a new IOCTL in the worst case. > > Maybe the NVIDIA folks can give us some hint on whether this is expected to > change at some point?
I think it's an ioctl, let's just leave out version/pad, adding a new ioctl isn't a major trouble if the world decides we need to do it. Also you can extend ioctls with new fields at the end without problems, so if it's just extra info it'll likely be hw specific and be part of enabling a new GPU. Dave.
