On Mon, Sep 13, 2021 at 10:54:14PM +0000, Souza, Jose wrote: > On Thu, 2021-09-09 at 23:28 +0300, Ville Syrjälä wrote: > > On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote: > > > On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote: > > > > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote: > > > > > By now all the userspace applications should have migrated to atomic > > > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB. > > > > > > > > > > With that we can kill frontbuffer rendering support in i915 for > > > > > modern platforms. > > > > > > > > > > So here converting legacy APIs into atomic commits so it can be > > > > > properly handled by driver i915. > > > > > > > > > > Several IGT tests will fail with this changes, because some tests > > > > > were stressing those frontbuffer rendering scenarios that no userspace > > > > > should be using by now, fixes to IGT should be sent soon. > > > > > > > > > > > > > I just gave this a try here and it's unusable. glxgears went from > > > > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get > > > > double), everything lags like mad, if I drag a window around > > > > glxgears/other windows stop updating entirely, etc. NAK > > > > > > Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks? > > > Will try it in my end. > > > > Doesn't really matter as long as you don't have a compositor making a > > mess of things. This machine is a cfl running mate w/ compositor off, > > and some 1920x1200 display. > > > > Making drm_atomic_helper_dirtyfb() do a non-blocking atomic commit makes user experience pretty similar to the one with compositing enabled: > drm_atomic_commit() + compositor off: https://youtu.be/NBt6smXs99U > drm_atomic_nonblocking_commit() + compositor off: https://youtu.be/QiMhkeGX_L8 > drm_atomic_nonblocking_commit() + compositor on: https://youtu.be/KdpJyJ5k6sQ > > > I do not completly agree with the comment in drm_atomic_helper_dirtyfb() about why it uses a blocking implementation. > With frontbuffer rendering the registers are programmed but the content could only show up for user a whole frame later. > > Perhaps if this solutions is accetable we could have a non-blocking version of drm_atomic_helper_dirtyfb() so the drivers current using it don't have > their behavior changed. Non-blocking update would make sense to me, whereas a blocking update makes no sense given how this is used by actual userspace. But this still changes the whole approach to eg. FBC nukes, so it's going to require some actual thought and testing to make sure it actually works as intended. I think by just essentially page flipping to the same buffer we're going to depend on semi-undefined behaviour for FBC. So I'm a bit worried that this is going to introduce new bugs. I have verified on ancient platforms that FBC does in fact flip nuke when flipping to the same buffer (and now we even (ab)use that fact in the frontbuffer tracking code), but I've not done that for any new platforms. The other concern is that introducing additional atomic commits this might trip up the page flip->-EBUSY stuff. Whether that is going to cause any real grief to userspace is unknown at this time. I guess we'd have to come up with a test that actually hits that and make sure the ddx doesn't get confused and instead just gracefully falls back to the blit path. -- Ville Syrjälä Intel
