On Wed, 23 Sep 2020 11:26:39 +0200 Daniel Vetter <[email protected]> wrote:
> I'm really not awake yet ... > > On Wed, Sep 23, 2020 at 10:17 AM Pekka Paalanen <[email protected]> wrote: > > > > On Tue, 22 Sep 2020 20:18:34 +0200 > > Daniel Vetter <[email protected]> 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
pgpoJ0Bwt7meR.pgp
Description: OpenPGP digital signature
_______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
