On Wed, 8 Jul 2020, Thomas Zimmermann wrote:
> Am 08.07.20 um 16:26 schrieb Daniel Vetter:
> > On Wed, Jul 8, 2020 at 4:22 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
> >>
> >> Am 08.07.20 um 15:46 schrieb Ilpo Järvinen:
> >>> On Wed, 8 Jul 2020, Thomas Zimmermann wrote:
> >>>
> >>>> Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
> >>>>>
> >>>>> 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.
Yes I know (it related only to in-kernel ast driver lacking 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.
Ah, so there is a technical obstacle. I thought that those 2nd copies of
buffers are only necessary during a switch from one resolution to another
one.
> > 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.
I cannot really understand full impact of this (what would not work).
> 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.
I'd highly appreciate that (but I guess I might quite small minority
when it comes to "ecosystems" :-)). And I wouldn't be too worried about
performance penalty.
--
i.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
