Hi Am 08.07.20 um 16:26 schrieb Daniel Vetter: > On Wed, Jul 8, 2020 at 4:22 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: >> >> 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) ;-). > > kms still has dpms, not sure what you mean here? Maybe some driver > doesn't implement it. > >>> 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. > > You can do high-res mode I think, maybe needs a driver option to allow > it to avoid upsetting existing compositors. Roughly: > 1. dpms off > 2. allocate big buffer > 3. dpms on in high res mode with that single buffer > > Pageflip will fail ofc with ENOSPC, but kms itself doesn't disallow > this. We could even implement this fairly generic, with a setcap flag, > which makes the probe helpers _not_ filter out modes which wouldn't > fit at least 2 framebuffers at the same time. Technically you can hack up something, but what's the benefit for the overall ecosystem? In my other reply, I was rather talking about replacing VRAM helpers with SHMEM helpers. That would imply a memcpy from system into video memory on each pageflip. OTOH, ast currently recommends using a shadow framebuffer, so userspace probably already does the memcpy somewhere. And now that SHMEM helpers can easily do cached page mappings, the performance difference might not be significant. Maybe I should give it a try. Best regards Thomas > -Daniel > >> 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 >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@xxxxxxxxxxxxxxxxxxxxx >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- 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
