Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, Sep 23, 2020 at 01:16:42PM +0200, Daniel Vetter wrote: > On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad wrote: > > > > On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote: > > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad > > > wrote: > > > > > > > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > > > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter > > > > > 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). > > > > > > > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > > > > which can lead to spurious EBUSY calls, both: > > > > > > - when that other CRTC is currently busy doing a page_flip the > > > > > > ALLOW_MODESET commit can fail with an EBUSY > > > > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > > > > of the additional commit inserted by the kernel without > > > > > > userspace's > > > > > > knowledge > > > > > > > > > > > > For blocking commits this isn't a problem, because everyone else > > > > > > will > > > > > > just block until all the CRTC are reconfigured. Only thing userspace > > > > > > can notice is the dropped frames without any reason for why frames > > > > > > got > > > > > > dropped. > > > > > > > > > > > > Consensus is that we need new uapi to handle this properly, but no > > > > > > one > > > > > > has any idea what exactly the new uapi should look like. As a > > > > > > stop-gap > > > > > > plug this problem by demoting nonblocking commits which might cause > > > > > > issues by including CRTCs not in the original request to blocking > > > > > > commits. > > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > > I've noticed this isn't integrated/added. > > > > > > > > Noticed this is fixing (also) DPMS when multiple outputs are in use. > > > > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). > > > > I'm seeing > > > > the warning quite often. > > > > > > On which driver/chip does this happen? > > I've tried it out on i915. > > lspci -nn please. Sure, $ lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers [8086:5914] (rev 08) 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 08) 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21) 00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21) 00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21) 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21) 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 [8086:9d10] (rev f1) 00:1c.2 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 [8086:9d12] (rev f1) 00:1c.4 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 [8086:9d14] (rev f1) 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 [8086:9d18] (rev f1) 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point LPC Controller/eSPI Controller [8086:9d4e] (rev 21) 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-LP PMC [8086:9d21] (rev 21) 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio [8086:9d71] (rev 21) 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 21) 01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader [10ec:525a] (rev 01) 02:00.0 Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter [168c:003e] (rev 32) 6e:00.0 Non-Volatile memory controller [0108]: Toshiba Corporation Device [1179:0116] (it's a xps laptop) > > Also adding Ville, who has an idea where this can all go wrong. The > one he pointed out thus far is gen12+ only though. > -Daniel > > > > -Daniel > > > > > > > > > > > > > > > > > Thanks for writing this up Daniel, and for reminding me about it some > > > > > time later as well ... > > > > > > > > > > Reviewed-by: Daniel Stone > > > > > > > > > > Cheers, > > > > > Daniel > > > > > ___ > > > > > dri-devel mailing list > > > > > dri-de...@lists.freedesktop.org > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > >
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, Sep 23, 2020 at 1:14 PM Marius Vlad wrote: > > On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote: > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad > > wrote: > > > > > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter > > > > 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). > > > > > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > > > which can lead to spurious EBUSY calls, both: > > > > > - when that other CRTC is currently busy doing a page_flip the > > > > > ALLOW_MODESET commit can fail with an EBUSY > > > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > > > of the additional commit inserted by the kernel without userspace's > > > > > knowledge > > > > > > > > > > For blocking commits this isn't a problem, because everyone else will > > > > > just block until all the CRTC are reconfigured. Only thing userspace > > > > > can notice is the dropped frames without any reason for why frames got > > > > > dropped. > > > > > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > > > plug this problem by demoting nonblocking commits which might cause > > > > > issues by including CRTCs not in the original request to blocking > > > > > commits. > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > I've noticed this isn't integrated/added. > > > > > > Noticed this is fixing (also) DPMS when multiple outputs are in use. > > > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm > > > seeing > > > the warning quite often. > > > > On which driver/chip does this happen? > I've tried it out on i915. lspci -nn please. Also adding Ville, who has an idea where this can all go wrong. The one he pointed out thus far is gen12+ only though. -Daniel > > -Daniel > > > > > > > > > > > > > Thanks for writing this up Daniel, and for reminding me about it some > > > > time later as well ... > > > > > > > > Reviewed-by: Daniel Stone > > > > > > > > Cheers, > > > > Daniel > > > > ___ > > > > dri-devel mailing list > > > > dri-de...@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, Sep 23, 2020 at 12:58:30PM +0200, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter 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). > > > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > > which can lead to spurious EBUSY calls, both: > > > > - when that other CRTC is currently busy doing a page_flip the > > > > ALLOW_MODESET commit can fail with an EBUSY > > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > > of the additional commit inserted by the kernel without userspace's > > > > knowledge > > > > > > > > For blocking commits this isn't a problem, because everyone else will > > > > just block until all the CRTC are reconfigured. Only thing userspace > > > > can notice is the dropped frames without any reason for why frames got > > > > dropped. > > > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > > plug this problem by demoting nonblocking commits which might cause > > > > issues by including CRTCs not in the original request to blocking > > > > commits. > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > I've noticed this isn't integrated/added. > > > > Noticed this is fixing (also) DPMS when multiple outputs are in use. > > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm > > seeing > > the warning quite often. > > On which driver/chip does this happen? I've tried it out on i915. > -Daniel > > > > > > > > > Thanks for writing this up Daniel, and for reminding me about it some > > > time later as well ... > > > > > > Reviewed-by: Daniel Stone > > > > > > Cheers, > > > Daniel > > > ___ > > > dri-devel mailing list > > > dri-de...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter 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). > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > which can lead to spurious EBUSY calls, both: > > > - when that other CRTC is currently busy doing a page_flip the > > > ALLOW_MODESET commit can fail with an EBUSY > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > of the additional commit inserted by the kernel without userspace's > > > knowledge > > > > > > For blocking commits this isn't a problem, because everyone else will > > > just block until all the CRTC are reconfigured. Only thing userspace > > > can notice is the dropped frames without any reason for why frames got > > > dropped. > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > plug this problem by demoting nonblocking commits which might cause > > > issues by including CRTCs not in the original request to blocking > > > commits. > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > I've noticed this isn't integrated/added. > > Noticed this is fixing (also) DPMS when multiple outputs are in use. > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm > seeing > the warning quite often. On which driver/chip does this happen? -Daniel > > > > > Thanks for writing this up Daniel, and for reminding me about it some > > time later as well ... > > > > Reviewed-by: Daniel Stone > > > > Cheers, > > Daniel > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
Hi, On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > I think we need a guarantee that this never happens if ALLOW_MODESET > > is always used in blocking mode, plus in future a cap we can use to > > detect that we won't be getting spurious EBUSY events. > > > > I really don't want to ever paper over this, because it's one of the > > clearest indications that userspace has its timing/signalling wrong. > > Ok so the hang-up last time around iirc was that I broke igt by making > a few things more synchronous. Let's hope I'm not also breaking stuff > with the WARN_ON ... > > New plan: > - make this patch here only document existing behaviour and enforce it > with the WARN_ON > - new uapi would be behind a flag or something, with userspace and > everything hanging off it. > > Thoughts? What do you mean by 'new uapi'? The proposal that the kernel communicates back which object IDs have been added to the state behind your back? That it's been made automatically blocking? Something else? Cheers, Daniel (the other one) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote: > > On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad > > wrote: > > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > > I've noticed this isn't integrated/added. > > > > Defacto the uapi we have now is that userspace needs to ignore "spurious" > > EBUSY. > > This really, really, really, bites. > > I think we need a guarantee that this never happens if ALLOW_MODESET > is always used in blocking mode, plus in future a cap we can use to > detect that we won't be getting spurious EBUSY events. > > I really don't want to ever paper over this, because it's one of the > clearest indications that userspace has its timing/signalling wrong. Ok so the hang-up last time around iirc was that I broke igt by making a few things more synchronous. Let's hope I'm not also breaking stuff with the WARN_ON ... New plan: - make this patch here only document existing behaviour and enforce it with the WARN_ON - new uapi would be behind a flag or something, with userspace and everything hanging off it. Thoughts? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote: > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > > I've noticed this isn't integrated/added. > > Defacto the uapi we have now is that userspace needs to ignore "spurious" > EBUSY. This really, really, really, bites. I think we need a guarantee that this never happens if ALLOW_MODESET is always used in blocking mode, plus in future a cap we can use to detect that we won't be getting spurious EBUSY events. I really don't want to ever paper over this, because it's one of the clearest indications that userspace has its timing/signalling wrong. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote: > > On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter 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). > > > > > > But in nonblocking mode userspace has then no idea this happened, > > > which can lead to spurious EBUSY calls, both: > > > - when that other CRTC is currently busy doing a page_flip the > > > ALLOW_MODESET commit can fail with an EBUSY > > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > > of the additional commit inserted by the kernel without userspace's > > > knowledge > > > > > > For blocking commits this isn't a problem, because everyone else will > > > just block until all the CRTC are reconfigured. Only thing userspace > > > can notice is the dropped frames without any reason for why frames got > > > dropped. > > > > > > Consensus is that we need new uapi to handle this properly, but no one > > > has any idea what exactly the new uapi should look like. As a stop-gap > > > plug this problem by demoting nonblocking commits which might cause > > > issues by including CRTCs not in the original request to blocking > > > commits. > Gentle ping. I've tried out Linus's master tree and, and like Pekka, > I've noticed this isn't integrated/added. Defacto the uapi we have now is that userspace needs to ignore "spurious" EBUSY. > Noticed this is fixing (also) DPMS when multiple outputs are in use. > Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm > seeing > the warning quite often. This would be a driver bug I think. That really shouldn't happen for normal page flips. -Daniel > > > > Thanks for writing this up Daniel, and for reminding me about it some > > time later as well ... > > > > Reviewed-by: Daniel Stone > > > > Cheers, > > Daniel > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote: > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter 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). > > > > But in nonblocking mode userspace has then no idea this happened, > > which can lead to spurious EBUSY calls, both: > > - when that other CRTC is currently busy doing a page_flip the > > ALLOW_MODESET commit can fail with an EBUSY > > - on the other CRTC a normal atomic flip can fail with EBUSY because > > of the additional commit inserted by the kernel without userspace's > > knowledge > > > > For blocking commits this isn't a problem, because everyone else will > > just block until all the CRTC are reconfigured. Only thing userspace > > can notice is the dropped frames without any reason for why frames got > > dropped. > > > > Consensus is that we need new uapi to handle this properly, but no one > > has any idea what exactly the new uapi should look like. As a stop-gap > > plug this problem by demoting nonblocking commits which might cause > > issues by including CRTCs not in the original request to blocking > > commits. Gentle ping. I've tried out Linus's master tree and, and like Pekka, I've noticed this isn't integrated/added. Noticed this is fixing (also) DPMS when multiple outputs are in use. Wondering if we can just use a _ONCE() variant instead of WARN_ON(). I'm seeing the warning quite often. > > Thanks for writing this up Daniel, and for reminding me about it some > time later as well ... > > Reviewed-by: Daniel Stone > > Cheers, > Daniel > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Thu, May 14, 2020 at 08:40:21AM +0100, Daniel Stone wrote: > On Thu, 14 May 2020 at 08:25, Daniel Vetter wrote: > > On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote: > > > On Thu, 14 May 2020 at 08:08, Daniel Vetter > > > wrote: > > > I'd be very much in favour of putting the blocking down in the kernel > > > at least until the kernel can give us a clear indication to tell us > > > what's going on, and ideally which other resources need to be dragged > > > in, in a way which is distinguishable from your compositor having > > > broken synchronisation. > > > > We know, the patch already computes that ... So would be a matter of > > exporting that to userspace. We have a mask of all additional crtc > > that will get an event and will -EBUSY until that's done. > > Yep, but unless and until that happens, could we please get this in? > Given it would require uAPI changes, we'd need to modify all the > compositors to work with the old path (random EBUSY) and the new path > (predictable and obvious), so at least preserving the promise that > per-CRTC updates are really independent would be good. I haven't found the time to look at the intel-gfx-ci fail in igt nor really think about that. Nor care enough to just hammer this ignoring ci, since I didn't even get around to understand why the igt now fails If someone else takes this over, happy to see it land. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Thu, 14 May 2020 at 08:25, Daniel Vetter wrote: > On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote: > > On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote: > > I'd be very much in favour of putting the blocking down in the kernel > > at least until the kernel can give us a clear indication to tell us > > what's going on, and ideally which other resources need to be dragged > > in, in a way which is distinguishable from your compositor having > > broken synchronisation. > > We know, the patch already computes that ... So would be a matter of > exporting that to userspace. We have a mask of all additional crtc > that will get an event and will -EBUSY until that's done. Yep, but unless and until that happens, could we please get this in? Given it would require uAPI changes, we'd need to modify all the compositors to work with the old path (random EBUSY) and the new path (predictable and obvious), so at least preserving the promise that per-CRTC updates are really independent would be good. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote: > > Hi, > > On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote: > > > Did anything happen with this? > > > > Nope. There's an igt now that fails with this, and I'm not sure > > whether changing the igt is the right idea or not. > > > > I'm kinda now thinking about changing this to instead document under > > which exact situations you can get a spurious EBUSY, and enforcing > > that in the code with some checks. Essentially only possible if you do > > a ALLOW_MODESET | NONBLOCKING on the other crtc. And then tell > > userspace you get to eat that. We've been shipping with this for so > > long by now that's defacto the uapi anyway :-/ > > > > Thoughts? Too horrible? > > I've been trying to avoid that, to be honest. Taking a random delay > because the kernel needs to do global things is fine. But making > userspace either do an expensive/complicated cross-CRTC > synchronisation is less easy; for some compositors, that means > reaching across threads to make sure all CRTCs are quiescent. Either > that, or deferring your ALLOW_MODESET to somewhere else, like an idle > handler, far away from where you were originally trying to do it, > which wouldn't be pleasant. The other option is that we teach people > to ignore EBUSY as random noise which can just sometimes happen and to > try again (when? how often? and you still have cross-CRTC > synchronisation issues), which doesn't scream compositor best practice > to me. > > I'd be very much in favour of putting the blocking down in the kernel > at least until the kernel can give us a clear indication to tell us > what's going on, and ideally which other resources need to be dragged > in, in a way which is distinguishable from your compositor having > broken synchronisation. We know, the patch already computes that ... So would be a matter of exporting that to userspace. We have a mask of all additional crtc that will get an event and will -EBUSY until that's done. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
Hi, On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote: > > Did anything happen with this? > > Nope. There's an igt now that fails with this, and I'm not sure > whether changing the igt is the right idea or not. > > I'm kinda now thinking about changing this to instead document under > which exact situations you can get a spurious EBUSY, and enforcing > that in the code with some checks. Essentially only possible if you do > a ALLOW_MODESET | NONBLOCKING on the other crtc. And then tell > userspace you get to eat that. We've been shipping with this for so > long by now that's defacto the uapi anyway :-/ > > Thoughts? Too horrible? I've been trying to avoid that, to be honest. Taking a random delay because the kernel needs to do global things is fine. But making userspace either do an expensive/complicated cross-CRTC synchronisation is less easy; for some compositors, that means reaching across threads to make sure all CRTCs are quiescent. Either that, or deferring your ALLOW_MODESET to somewhere else, like an idle handler, far away from where you were originally trying to do it, which wouldn't be pleasant. The other option is that we teach people to ignore EBUSY as random noise which can just sometimes happen and to try again (when? how often? and you still have cross-CRTC synchronisation issues), which doesn't scream compositor best practice to me. I'd be very much in favour of putting the blocking down in the kernel at least until the kernel can give us a clear indication to tell us what's going on, and ideally which other resources need to be dragged in, in a way which is distinguishable from your compositor having broken synchronisation. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Thu, May 14, 2020 at 8:42 AM Daniel Stone wrote: > > On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote: > > Resending because last attempt failed CI and meanwhile the results are > > lost :-/ > > Did anything happen with this? Nope. There's an igt now that fails with this, and I'm not sure whether changing the igt is the right idea or not. I'm kinda now thinking about changing this to instead document under which exact situations you can get a spurious EBUSY, and enforcing that in the code with some checks. Essentially only possible if you do a ALLOW_MODESET | NONBLOCKING on the other crtc. And then tell userspace you get to eat that. We've been shipping with this for so long by now that's defacto the uapi anyway :-/ Thoughts? Too horrible? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote: > Resending because last attempt failed CI and meanwhile the results are > lost :-/ Did anything happen with this? Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Wed, Apr 8, 2020 at 4:03 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter 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).
> > > > >
> > > > > But in nonblocking mode userspace has then no idea this happened,
> > > > > which can lead to spurious EBUSY calls, both:
> > > > > - when that other CRTC is currently busy doing a page_flip the
> > > > > ALLOW_MODESET commit can fail with an EBUSY
> > > > > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > > > > of the additional commit inserted by the kernel without userspace's
> > > > > knowledge
> > > > >
> > > > > For blocking commits this isn't a problem, because everyone else will
> > > > > just block until all the CRTC are reconfigured. Only thing userspace
> > > > > can notice is the dropped frames without any reason for why frames got
> > > > > dropped.
> > > > >
> > > > > Consensus is that we need new uapi to handle this properly, but no one
> > > > > has any idea what exactly the new uapi should look like. As a stop-gap
> > > > > plug this problem by demoting nonblocking commits which might cause
> > > > > issues by including CRTCs not in the original request to blocking
> > > > > commits.
> > > > >
> > > > > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > > > > don't want to silently convert page flips into blocking plane updates
> > > > > just because the driver is buggy.
> > > > >
> > > > > v3: Fix inverted WARN_ON (Pekka).
> > > > >
> > > > > References:
> > > > > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > > > > Bugzilla:
> > > > > https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > > > > Cc: Daniel Stone
> > > > > Cc: Pekka Paalanen
> > > > > Cc: sta...@vger.kernel.org
> > > > > Reviewed-by: Daniel Stone
> > > > > Signed-off-by: Daniel Vetter
> > > > > ---
> > > > > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > > > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > > > b/drivers/gpu/drm/drm_atomic.c
> > > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > > > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > > > {
> > > > > struct drm_mode_config *config = &state->dev->mode_config;
> > > > > - int ret;
> > > > > + unsigned requested_crtc = 0;
> > > > > + unsigned affected_crtc = 0;
> > > > > + struct drm_crtc *crtc;
> > > > > + struct drm_crtc_state *crtc_state;
> > > > > + bool nonblocking = true;
> > > > > + int ret, i;
> > > > > +
> > > > > + /*
> > > > > + * For commits that allow modesets drivers can add other CRTCs
> > > > > to the
> > > > > + * atomic commit, e.g. when they need to reallocate global
> > > > > resources.
> > > > > + *
> > > > > + * But when userspace also requests a nonblocking commit then
> > > > > userspace
> > > > > + * cannot know that the commit affects other CRTCs, which can
> > > > > result in
> > > > > + * spurious EBUSY failures. Until we have better uapi plug this
> > > > > by
> > > > > + * demoting such commits to blocking mode.
> > > > > + */
> > > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > + requested_crtc |= drm_crtc_mask(crtc);
> > > > >
> > > > > ret = drm_atomic_check_only(state);
> > > > > if (ret)
> > > > > return ret;
> > > > >
> > > > > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > > +
> > > > > + if (affected_crtc != requested_crtc) {
> > > > > + /* adding other CRTC is only allowed for modeset
> > > > > commits */
> > > > > + WARN_ON(!state->allow_modeset);
> > > >
> > > > Not sure that's really true. What if the driver needs to eg.
> > > > redistribute FIFO space or something between the pipes? Or do we
> > > > expect drivers to now examine state->allow_modeset to figure out
> > > > if they're allowed to do certain things?
> > >
> > > Maybe we need more fine-grained flags here, but adding other states
> > > (and blocking a commit flow) is exactly the uapi headaches this patch
> > > tries to solve here. So if our driver currently adds crtc states to
> > > reallocate fifo between pipes for an
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > wrote:
> > >
> > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter 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).
> > > >
> > > > But in nonblocking mode userspace has then no idea this happened,
> > > > which can lead to spurious EBUSY calls, both:
> > > > - when that other CRTC is currently busy doing a page_flip the
> > > > ALLOW_MODESET commit can fail with an EBUSY
> > > > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > > > of the additional commit inserted by the kernel without userspace's
> > > > knowledge
> > > >
> > > > For blocking commits this isn't a problem, because everyone else will
> > > > just block until all the CRTC are reconfigured. Only thing userspace
> > > > can notice is the dropped frames without any reason for why frames got
> > > > dropped.
> > > >
> > > > Consensus is that we need new uapi to handle this properly, but no one
> > > > has any idea what exactly the new uapi should look like. As a stop-gap
> > > > plug this problem by demoting nonblocking commits which might cause
> > > > issues by including CRTCs not in the original request to blocking
> > > > commits.
> > > >
> > > > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > > > don't want to silently convert page flips into blocking plane updates
> > > > just because the driver is buggy.
> > > >
> > > > v3: Fix inverted WARN_ON (Pekka).
> > > >
> > > > References:
> > > > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > > > Bugzilla:
> > > > https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > > > Cc: Daniel Stone
> > > > Cc: Pekka Paalanen
> > > > Cc: sta...@vger.kernel.org
> > > > Reviewed-by: Daniel Stone
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > > {
> > > > struct drm_mode_config *config = &state->dev->mode_config;
> > > > - int ret;
> > > > + unsigned requested_crtc = 0;
> > > > + unsigned affected_crtc = 0;
> > > > + struct drm_crtc *crtc;
> > > > + struct drm_crtc_state *crtc_state;
> > > > + bool nonblocking = true;
> > > > + int ret, i;
> > > > +
> > > > + /*
> > > > + * For commits that allow modesets drivers can add other CRTCs to
> > > > the
> > > > + * atomic commit, e.g. when they need to reallocate global
> > > > resources.
> > > > + *
> > > > + * But when userspace also requests a nonblocking commit then
> > > > userspace
> > > > + * cannot know that the commit affects other CRTCs, which can
> > > > result in
> > > > + * spurious EBUSY failures. Until we have better uapi plug this by
> > > > + * demoting such commits to blocking mode.
> > > > + */
> > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > + requested_crtc |= drm_crtc_mask(crtc);
> > > >
> > > > ret = drm_atomic_check_only(state);
> > > > if (ret)
> > > > return ret;
> > > >
> > > > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > + affected_crtc |= drm_crtc_mask(crtc);
> > > > +
> > > > + if (affected_crtc != requested_crtc) {
> > > > + /* adding other CRTC is only allowed for modeset commits
> > > > */
> > > > + WARN_ON(!state->allow_modeset);
> > >
> > > Not sure that's really true. What if the driver needs to eg.
> > > redistribute FIFO space or something between the pipes? Or do we
> > > expect drivers to now examine state->allow_modeset to figure out
> > > if they're allowed to do certain things?
> >
> > Maybe we need more fine-grained flags here, but adding other states
> > (and blocking a commit flow) is exactly the uapi headaches this patch
> > tries to solve here. So if our driver currently adds crtc states to
> > reallocate fifo between pipes for an atomic flip then yes we're
> > breaking userspace. Well, everyone figured out by now that you get
> > random EBUSY and dropped frames for no apparent reason at all, and
> > work around it. But happy, they are not.
>
> I don't think we do this currently for the FIFO, but in theor
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> wrote:
> >
> > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter 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).
> > >
> > > But in nonblocking mode userspace has then no idea this happened,
> > > which can lead to spurious EBUSY calls, both:
> > > - when that other CRTC is currently busy doing a page_flip the
> > > ALLOW_MODESET commit can fail with an EBUSY
> > > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > > of the additional commit inserted by the kernel without userspace's
> > > knowledge
> > >
> > > For blocking commits this isn't a problem, because everyone else will
> > > just block until all the CRTC are reconfigured. Only thing userspace
> > > can notice is the dropped frames without any reason for why frames got
> > > dropped.
> > >
> > > Consensus is that we need new uapi to handle this properly, but no one
> > > has any idea what exactly the new uapi should look like. As a stop-gap
> > > plug this problem by demoting nonblocking commits which might cause
> > > issues by including CRTCs not in the original request to blocking
> > > commits.
> > >
> > > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > > don't want to silently convert page flips into blocking plane updates
> > > just because the driver is buggy.
> > >
> > > v3: Fix inverted WARN_ON (Pekka).
> > >
> > > References:
> > > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > > Bugzilla:
> > > https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > > Cc: Daniel Stone
> > > Cc: Pekka Paalanen
> > > Cc: sta...@vger.kernel.org
> > > Reviewed-by: Daniel Stone
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > > 1 file changed, 31 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 9ccfbf213d72..4c035abf98b8 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > {
> > > struct drm_mode_config *config = &state->dev->mode_config;
> > > - int ret;
> > > + unsigned requested_crtc = 0;
> > > + unsigned affected_crtc = 0;
> > > + struct drm_crtc *crtc;
> > > + struct drm_crtc_state *crtc_state;
> > > + bool nonblocking = true;
> > > + int ret, i;
> > > +
> > > + /*
> > > + * For commits that allow modesets drivers can add other CRTCs to
> > > the
> > > + * atomic commit, e.g. when they need to reallocate global
> > > resources.
> > > + *
> > > + * But when userspace also requests a nonblocking commit then
> > > userspace
> > > + * cannot know that the commit affects other CRTCs, which can
> > > result in
> > > + * spurious EBUSY failures. Until we have better uapi plug this by
> > > + * demoting such commits to blocking mode.
> > > + */
> > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > + requested_crtc |= drm_crtc_mask(crtc);
> > >
> > > ret = drm_atomic_check_only(state);
> > > if (ret)
> > > return ret;
> > >
> > > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > + affected_crtc |= drm_crtc_mask(crtc);
> > > +
> > > + if (affected_crtc != requested_crtc) {
> > > + /* adding other CRTC is only allowed for modeset commits */
> > > + WARN_ON(!state->allow_modeset);
> >
> > Not sure that's really true. What if the driver needs to eg.
> > redistribute FIFO space or something between the pipes? Or do we
> > expect drivers to now examine state->allow_modeset to figure out
> > if they're allowed to do certain things?
>
> Maybe we need more fine-grained flags here, but adding other states
> (and blocking a commit flow) is exactly the uapi headaches this patch
> tries to solve here. So if our driver currently adds crtc states to
> reallocate fifo between pipes for an atomic flip then yes we're
> breaking userspace. Well, everyone figured out by now that you get
> random EBUSY and dropped frames for no apparent reason at all, and
> work around it. But happy, they are not.
I don't think we do this currently for the FIFO, but in theory we
could.
The one thing we might do currently is cdclk reprogramming, but that
can only happen without a full modeset when there's only a single
active pipe. So we shouldn't hit this right now. But that restriction
is going to disappear in the future, at which point we may want
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter 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).
> >
> > But in nonblocking mode userspace has then no idea this happened,
> > which can lead to spurious EBUSY calls, both:
> > - when that other CRTC is currently busy doing a page_flip the
> > ALLOW_MODESET commit can fail with an EBUSY
> > - on the other CRTC a normal atomic flip can fail with EBUSY because
> > of the additional commit inserted by the kernel without userspace's
> > knowledge
> >
> > For blocking commits this isn't a problem, because everyone else will
> > just block until all the CRTC are reconfigured. Only thing userspace
> > can notice is the dropped frames without any reason for why frames got
> > dropped.
> >
> > Consensus is that we need new uapi to handle this properly, but no one
> > has any idea what exactly the new uapi should look like. As a stop-gap
> > plug this problem by demoting nonblocking commits which might cause
> > issues by including CRTCs not in the original request to blocking
> > commits.
> >
> > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > don't want to silently convert page flips into blocking plane updates
> > just because the driver is buggy.
> >
> > v3: Fix inverted WARN_ON (Pekka).
> >
> > References:
> > https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > Cc: Daniel Stone
> > Cc: Pekka Paalanen
> > Cc: sta...@vger.kernel.org
> > Reviewed-by: Daniel Stone
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic.c | 34 +++---
> > 1 file changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 9ccfbf213d72..4c035abf98b8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > {
> > struct drm_mode_config *config = &state->dev->mode_config;
> > - int ret;
> > + unsigned requested_crtc = 0;
> > + unsigned affected_crtc = 0;
> > + struct drm_crtc *crtc;
> > + struct drm_crtc_state *crtc_state;
> > + bool nonblocking = true;
> > + int ret, i;
> > +
> > + /*
> > + * For commits that allow modesets drivers can add other CRTCs to the
> > + * atomic commit, e.g. when they need to reallocate global resources.
> > + *
> > + * But when userspace also requests a nonblocking commit then
> > userspace
> > + * cannot know that the commit affects other CRTCs, which can result
> > in
> > + * spurious EBUSY failures. Until we have better uapi plug this by
> > + * demoting such commits to blocking mode.
> > + */
> > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > + requested_crtc |= drm_crtc_mask(crtc);
> >
> > ret = drm_atomic_check_only(state);
> > if (ret)
> > return ret;
> >
> > - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > + affected_crtc |= drm_crtc_mask(crtc);
> > +
> > + if (affected_crtc != requested_crtc) {
> > + /* adding other CRTC is only allowed for modeset commits */
> > + WARN_ON(!state->allow_modeset);
>
> Not sure that's really true. What if the driver needs to eg.
> redistribute FIFO space or something between the pipes? Or do we
> expect drivers to now examine state->allow_modeset to figure out
> if they're allowed to do certain things?
Maybe we need more fine-grained flags here, but adding other states
(and blocking a commit flow) is exactly the uapi headaches this patch
tries to solve here. So if our driver currently adds crtc states to
reallocate fifo between pipes for an atomic flip then yes we're
breaking userspace. Well, everyone figured out by now that you get
random EBUSY and dropped frames for no apparent reason at all, and
work around it. But happy, they are not.
Also we've already crossed that bridge a bit with mucking around with
allow_modeset from driver code with the self refresh helpers.
Cheers, Daniel
>
> > +
> > + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid
> > EBUSY\n", state);
> > + nonblocking = false;
> > + } else {
> > + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > + }
> >
> > - return config->funcs->atomic_commit(state->dev, state, true);
> > + return config->funcs->atomic_commit(state->dev, state, nonblocking);
> > }
> > EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
> >
> > --
> >
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter 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).
>
> But in nonblocking mode userspace has then no idea this happened,
> which can lead to spurious EBUSY calls, both:
> - when that other CRTC is currently busy doing a page_flip the
> ALLOW_MODESET commit can fail with an EBUSY
> - on the other CRTC a normal atomic flip can fail with EBUSY because
> of the additional commit inserted by the kernel without userspace's
> knowledge
>
> For blocking commits this isn't a problem, because everyone else will
> just block until all the CRTC are reconfigured. Only thing userspace
> can notice is the dropped frames without any reason for why frames got
> dropped.
>
> Consensus is that we need new uapi to handle this properly, but no one
> has any idea what exactly the new uapi should look like. As a stop-gap
> plug this problem by demoting nonblocking commits which might cause
> issues by including CRTCs not in the original request to blocking
> commits.
>
> v2: Add comments and a WARN_ON to enforce this only when allowed - we
> don't want to silently convert page flips into blocking plane updates
> just because the driver is buggy.
>
> v3: Fix inverted WARN_ON (Pekka).
>
> References:
> https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> Cc: Daniel Stone
> Cc: Pekka Paalanen
> Cc: sta...@vger.kernel.org
> Reviewed-by: Daniel Stone
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 34 +++---
> 1 file changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9ccfbf213d72..4c035abf98b8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> {
> struct drm_mode_config *config = &state->dev->mode_config;
> - int ret;
> + unsigned requested_crtc = 0;
> + unsigned affected_crtc = 0;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + bool nonblocking = true;
> + int ret, i;
> +
> + /*
> + * For commits that allow modesets drivers can add other CRTCs to the
> + * atomic commit, e.g. when they need to reallocate global resources.
> + *
> + * But when userspace also requests a nonblocking commit then userspace
> + * cannot know that the commit affects other CRTCs, which can result in
> + * spurious EBUSY failures. Until we have better uapi plug this by
> + * demoting such commits to blocking mode.
> + */
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> + requested_crtc |= drm_crtc_mask(crtc);
>
> ret = drm_atomic_check_only(state);
> if (ret)
> return ret;
>
> - DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
> +
> + if (affected_crtc != requested_crtc) {
> + /* adding other CRTC is only allowed for modeset commits */
> + WARN_ON(!state->allow_modeset);
Not sure that's really true. What if the driver needs to eg.
redistribute FIFO space or something between the pipes? Or do we
expect drivers to now examine state->allow_modeset to figure out
if they're allowed to do certain things?
> +
> + DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid
> EBUSY\n", state);
> + nonblocking = false;
> + } else {
> + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> + }
>
> - return config->funcs->atomic_commit(state->dev, state, true);
> + return config->funcs->atomic_commit(state->dev, state, nonblocking);
> }
> EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
>
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Thu, 5 Jul 2018 at 11:21, Daniel Vetter 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). > > But in nonblocking mode userspace has then no idea this happened, > which can lead to spurious EBUSY calls, both: > - when that other CRTC is currently busy doing a page_flip the > ALLOW_MODESET commit can fail with an EBUSY > - on the other CRTC a normal atomic flip can fail with EBUSY because > of the additional commit inserted by the kernel without userspace's > knowledge > > For blocking commits this isn't a problem, because everyone else will > just block until all the CRTC are reconfigured. Only thing userspace > can notice is the dropped frames without any reason for why frames got > dropped. > > Consensus is that we need new uapi to handle this properly, but no one > has any idea what exactly the new uapi should look like. As a stop-gap > plug this problem by demoting nonblocking commits which might cause > issues by including CRTCs not in the original request to blocking > commits. Thanks for writing this up Daniel, and for reminding me about it some time later as well ... Reviewed-by: Daniel Stone Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
