On Wed, 23 Sep 2020 11:26:39 +0200 Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > I'm really not awake yet ... > > On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > > > On Tue, 22 Sep 2020 20:18:34 +0200 > > Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > pull in arbitrary other resources, including CRTCs (e.g. when > > > reconfiguring global resources). > > If yes, and *if* userspace is single-threaded wrt. to KMS updates, > > that might offer a way to work around it in userspace. But if userspace > > is flipping other CRTCs from other threads, TEST_ONLY commit does not > > help because another thread may cut in and make a CRTC busy. > > This is not a legit programming model for atomic. An atomic commit is > always relative to the current state. If that state changes, then you > need to re-run your TEST_ONLY commit. So multiple threads changing > state in parallel isn't really a good idea anyway. Minimally we'd need > some kind of TEST_ONLY pile-up, so you can validate a change assuming > another commit has already happened. That's even harder than deep > queues on the commit side, we'd probably need full rollback of > commits. Yes, very good point. I forgot that for a moment. Thanks, pq
Attachment:
pgpk8fJOGbc2Z.pgp
Description: OpenPGP digital signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
