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

[Thomas Zimmermann]

Hi

Am 08.07.20 um 16:26 schrieb 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.

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 at lists.freedesktop.org
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 516 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200708/1cad57a4/attachment.sig>