Hi Am 08.07.20 um 16:22 schrieb Thomas Zimmermann: > Hi > > Am 08.07.20 um 15:46 schrieb Ilpo Järvinen: >> On Wed, 8 Jul 2020, Thomas Zimmermann wrote: >> >>> Hi >>> >>> Am 08.07.20 um 12:05 schrieb Ilpo Järvinen: >>>> Hi, >>>> >>>> After upgrading kernel from 5.3 series to 5.6.16 something seems to >>>> prevent me from achieving high resolutions with the ast driver. >>> >>> Thanks for reporting. It's not a bug, but a side effect of atomic >>> modesetting. >>> >>> During pageflips, the old code used to kick out the currently displayed >>> framebuffer and then load in the new one. If that failed, the display >>> went garbage. >>> >>> In v5.6-rc1, we merged atomic modesetting for ast. This means that >>> screen updates are more reliable, but we have to over-commit resources. >>> Specifically, we have to reserve space for two buffers in video memory >>> while a pageflip happens. 1920x1200@32 are ~9MiB of framebuffer memory. >>> If your device has 16 MiB of VRAM, there's no space left for the second >>> framebuffer. Hence, the resolution is no longer supported. >>> >>> On the positive side, you can now use Wayland compositors with ast. >>> Atomic modesetting adds the necessary interfaces. >> >> Ok, thanks for the info although it's quite disappointing (not the first >> time to lose features with kms, migrating to it made me to lose dpms) ;-). >> >> As it's quite annoying to lose a high resolution mode (or be stuck in >> some old kernel), would it be technically feasible to make the framebuffer >> allocation asymmetrical? That is, the switch to high-res mode would get >> rejected when it would be into the smaller of the two buffers but not when >> the arrangement is the other way around? > > I'm not sure what you mean here, but generally, there's no way of fixing > this without performance penalty. I actually considered this, but didn't think it was worth it. The high-res modes would be sluggish. But then again, they already were, so it might not make much of a difference... Best regards Thomas > > The screen resolution is only programmed once. Later updates only > require pageflips. For each pageflip, atomic modesetting requires the > new and the old framebuffer in video memory at the same time. These two > framebuffers are typically allocated once by Gnome/KDE/etc compositors, > and compositors go back and forth between them. It's basically double > buffering. > > Best regards > Thomas > >> >> > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
