drm/ast something ate high-res modes (5.3->5.6 regression)

[Daniel Vetter]

On Wed, Jul 8, 2020 at 4:22 PM Thomas Zimmermann <tzimmermann at suse.de> 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 at 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.
-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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch