On Wed, 2021-09-15 at 16:48 +0300, Ville Syrjälä wrote: > 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. I believe the current fbc tests in kms_frontbuffer_tracking already stress this. For PSR2 hardware tracking in SKL and TGL I have validated(PSR2 is not covered by kms_frontbuffer_tracking due pipe CRC not work with it) this and flipping to the same buffer causes the hardware to properly update the screen. > > 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. >
