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

[Thomas Zimmermann]

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

-------------- 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/94a4c670/attachment.sig>