On Wed, Dec 13, 2023 at 05:29:12PM +0200, Ville Syrjälä wrote: > On Wed, Dec 13, 2023 at 05:15:06PM +0200, Ville Syrjälä wrote: > > On Wed, Dec 13, 2023 at 01:28:15PM +0200, Lisovskiy, Stanislav wrote: > > > On Wed, Dec 13, 2023 at 12:25:19PM +0200, Ville Syrjala wrote: > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > This reverts commit cfeff354f70bb1d0deb0279506e3f7989bc16e28. > > > > > > > > A core design consideration with legacy cursor updates is that the > > > > cursor must not touch any other plane, even if we were to force it > > > > to take the slow path. That is the real reason why the cursor uses > > > > a fixed ddb allocation, not because bspec says so. > > > > > > > > Treating cursors as any other plane during ddb allocation > > > > violates that, which means we can now pull other planes into > > > > fully unsynced legacy cursor mailbox commits. That is > > > > definitely not something we've ever considered when designing > > > > the rest of the code. The noarm+arm register write split in > > > > particular makes that dangerous as previous updates can get > > > > disarmed pretty much at any random time, and not necessarily > > > > in an order that is actually safe (eg. against ddb overlaps). > > > > > > > > So if we were to do this then: > > > > - someone needs to expend the appropriate amount of brain > > > > cells thinking through all the tricky details > > > > > > So question is how can we avoid pulling other planes to the commit?.. > > > > By preallocating the ddb, as we do already. > > I guess one thing we could consider is allcating the cursor ddb > based on the cursors real size (as opposed to always allocating for > 256x256 cursor), and not doing a mailbox update when changing size. > But as we learn in https://gitlab.freedesktop.org/drm/intel/-/issues/7687: > - current userspace always uses 256x256 until the PLANE_SIZE_HINTS > stuff (or something similar) lands, so there is no point > - it would lead to worse power consumption with smaller cursors > as there isn't enough extra ddb. The fact that we currently > allocate the minimum for 256x256 means smallers cursor sizes > are more efficient. Some tests I did also indicated that the > current code does not give optimal values even if we let it > fully calculate the extra ddb like in the reverted commit here. > We really need someone to take a proper look at how to tune > the ddb allocation for optimal power consumption... Oh, and another random idea I keep having occasionally would be to by default assume that legacy cursor uapi wouldn't be used, and then massage stuff sufficiently when the first use appears to make it work well from that point onwards. That way we could try to be a bit more optimal with ddb/other stuff for userspace that never uses the legacy cursor uapi. But haven't really thought through the details on this one. -- Ville Syrjälä Intel
