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. 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
