On Wed, Sep 15, 2021 at 06:57:19PM +0300, Ville Syrjälä wrote: > On Wed, Sep 15, 2021 at 04:48:49PM +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. > > Actually neither maybe makes total sense since userspace probably > isn't expecting -EBUSY from dirtyfb. So we might end up with stale > junk on the screen if no further updates come in after an -EBUSY. One option would be to teach userspace to retry after an -EBUSY, but without a completion event from dirtyfb it's going to be hard to know when to retry. > > The current frontbuffer stuff works much more like a mailbox style > update so we don't lose stuff and neither do we block. I suppose the obvious solution would be to teach kms to do proper mailbox updates. But that is not entirely trivial. One way to simplify the proposal a bit is to limit it to pure pageflips, which would suffice for dirtyfb as well obviously. That way watermarks and other potentially tricky stuff wouldn't change. But actually figuring out the proper commit sequence for this might take some doing. The way I think it should work is that we just let each commit through without blocking on the previous one. A later commit may simply overwrite the hardware registers before the values written by the previous commit get latched. The vblank evasion stuff would make it perfectly safe. The hardest thing there is probably figuring out how to handle all the pre/post_plane_update() stuff properly since we can't know ahead of time whether the flip gets latched or not, and so we can't really use the old state during state computation to make any decisions affecting our future behaviour. But given that async flips are more or less working today might mean that I'm worried about nothing. Either that or async flips are in fact broken in some funny ways I've not yet realized... The other problem for actual mailbox page flips is completion events/out fences. The current out fence I think is not really suitable for cases where a flip ends up getting overwritten by a later one, and thus the fb rotation no longer follows the normal fifo order. But of we don't expose actual mailbox page flips through the uapi then we could avoid worrying about this stuff initially. -- Ville Syrjälä Intel
