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

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

[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.

With 5.6.16:

$ xrandr
Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 2048
VGA-1 connected primary 1600x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
   1600x1200     60.00* 
   1680x1050     59.95  
   1280x1024     75.02    60.02  
   1440x900      59.89  
   1280x800      59.81  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
   1920x1200_60.0  59.95  

If I try to change to that manually added high-res mode, I get:
xrandr: Configure crtc 0 failed

With 5.3 series I've this:

Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 2048
VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
   1920x1200     59.95*+
   1600x1200     60.00  
   1680x1050     59.95  
   1280x1024     75.02    60.02  
   1440x900      59.89  
   1280x800      59.81  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
   1920x1200_60.0  59.95  

As I've had issues in getting EDID reliably from the monitor, I provide it 
on kernel command-line (the one dumped from the monitor I use). In 
addition, I've another workaround for past issues related to EDID which 
always adds that 1920x1200_60.0 mode but now I cannot use even it to
enter a high-res mode.

If you need some additional info or want me to test a patch, just let me 
know (but some delay is expected in testing patches). Thanks.


-- 
 i.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 2827 bytes --]

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.

Best regards
Thomas

> 
> With 5.6.16:
> 
> $ xrandr
> Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 2048
> VGA-1 connected primary 1600x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
>    1600x1200     60.00* 
>    1680x1050     59.95  
>    1280x1024     75.02    60.02  
>    1440x900      59.89  
>    1280x800      59.81  
>    1024x768      75.03    60.00  
>    800x600       75.00    60.32  
>    640x480       75.00    59.94  
>    1920x1200_60.0  59.95  
> 
> If I try to change to that manually added high-res mode, I get:
> xrandr: Configure crtc 0 failed
> 
> With 5.3 series I've this:
> 
> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 2048
> VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
>    1920x1200     59.95*+
>    1600x1200     60.00  
>    1680x1050     59.95  
>    1280x1024     75.02    60.02  
>    1440x900      59.89  
>    1280x800      59.81  
>    1024x768      75.03    60.00  
>    800x600       75.00    60.32  
>    640x480       75.00    59.94  
>    1920x1200_60.0  59.95  
> 
> As I've had issues in getting EDID reliably from the monitor, I provide it 
> on kernel command-line (the one dumped from the monitor I use). In 
> addition, I've another workaround for past issues related to EDID which 
> always adds that 1920x1200_60.0 mode but now I cannot use even it to
> enter a high-res mode.
> 
> If you need some additional info or want me to test a patch, just let me 
> know (but some delay is expected in testing patches). Thanks.
> 
> 

-- 
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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

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

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.

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 2376 bytes --]

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 2712 bytes --]

Hi

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

I actually considered this, but didn't think it was worth it. The
high-res modes would be sluggish. But then again, they already were, so
it might not make much of a difference...

Best regards
Thomas

> 
> 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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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@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@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 4206 bytes --]

Hi

Am 08.07.20 um 16:26 schrieb Daniel Vetter:
> On Wed, Jul 8, 2020 at 4:22 PM Thomas Zimmermann <tzimmermann@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@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@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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 4126 bytes --]

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@suse.de> 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.

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thomas Zimmermann]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 2525 bytes --]

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.

Are you able to build and run a test kernel?

I'm seriously considering moving ast to the SHMEM memory manager, which
would restore the higher resolutions.

If you're able to test, you need the git tree drm-tip/drm-tip and the
attached patch.

Alternatively, I've pushed all to

  https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/ast-shmem

You'd have to checkout the tree and switch to the ast-shmem branch.

Please report back if that solves the issue for you.

Best regards
Thomas

> 
> With 5.6.16:
> 
> $ xrandr
> Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 2048
> VGA-1 connected primary 1600x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
>    1600x1200     60.00* 
>    1680x1050     59.95  
>    1280x1024     75.02    60.02  
>    1440x900      59.89  
>    1280x800      59.81  
>    1024x768      75.03    60.00  
>    800x600       75.00    60.32  
>    640x480       75.00    59.94  
>    1920x1200_60.0  59.95  
> 
> If I try to change to that manually added high-res mode, I get:
> xrandr: Configure crtc 0 failed
> 
> With 5.3 series I've this:
> 
> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 2048
> VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
>    1920x1200     59.95*+
>    1600x1200     60.00  
>    1680x1050     59.95  
>    1280x1024     75.02    60.02  
>    1440x900      59.89  
>    1280x800      59.81  
>    1024x768      75.03    60.00  
>    800x600       75.00    60.32  
>    640x480       75.00    59.94  
>    1920x1200_60.0  59.95  
> 
> As I've had issues in getting EDID reliably from the monitor, I provide it 
> on kernel command-line (the one dumped from the monitor I use). In 
> addition, I've another workaround for past issues related to EDID which 
> always adds that 1920x1200_60.0 mode but now I cannot use even it to
> enter a high-res mode.
> 
> If you need some additional info or want me to test a patch, just let me 
> know (but some delay is expected in testing patches). Thanks.
> 
> 

-- 
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 #1.1.1.2: 0001-drm-ast-Convert-ast-to-SHMEM.patch --]
[-- Type: text/x-patch, Size: 13850 bytes --]

From ea15b5d52a4538e40da9605d71ed52baa1c1cdd7 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann <tzimmermann@suse.de>
Date: Thu, 9 Jul 2020 14:06:43 +0200
Subject: [PATCH] drm/ast: Convert ast to SHMEM

---
 drivers/gpu/drm/ast/Kconfig      |  4 +-
 drivers/gpu/drm/ast/ast_cursor.c | 95 ++++++++------------------------
 drivers/gpu/drm/ast/ast_drv.c    |  5 +-
 drivers/gpu/drm/ast/ast_drv.h    |  8 ++-
 drivers/gpu/drm/ast/ast_main.c   |  1 -
 drivers/gpu/drm/ast/ast_mm.c     | 32 +++++++----
 drivers/gpu/drm/ast/ast_mode.c   | 75 +++++++++++++++++++------
 7 files changed, 112 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
index fbcf2f45cef5..d367a90cd3de 100644
--- a/drivers/gpu/drm/ast/Kconfig
+++ b/drivers/gpu/drm/ast/Kconfig
@@ -2,10 +2,8 @@
 config DRM_AST
 	tristate "AST server chips"
 	depends on DRM && PCI && MMU
+	select DRM_GEM_SHMEM_HELPER
 	select DRM_KMS_HELPER
-	select DRM_VRAM_HELPER
-	select DRM_TTM
-	select DRM_TTM_HELPER
 	help
 	 Say yes for experimental AST GPU driver. Do not enable
 	 this driver without having a working -modesetting,
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index e0f4613918ad..ad4b02967d32 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -27,79 +27,39 @@
  * Authors: Dave Airlie <airlied@redhat.com>
  */
 
-#include <drm/drm_gem_vram_helper.h>
+#include <drm/drm_gem_shmem_helper.h>
 #include <drm/drm_managed.h>
 
 #include "ast_drv.h"
 
-static void ast_cursor_fini(struct ast_private *ast)
-{
-	size_t i;
-	struct drm_gem_vram_object *gbo;
-
-	for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
-		gbo = ast->cursor.gbo[i];
-		drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
-		drm_gem_vram_unpin(gbo);
-		drm_gem_vram_put(gbo);
-	}
-}
-
-static void ast_cursor_release(struct drm_device *dev, void *ptr)
-{
-	struct ast_private *ast = to_ast_private(dev);
-
-	ast_cursor_fini(ast);
-}
-
 /*
  * Allocate cursor BOs and pins them at the end of VRAM.
  */
 int ast_cursor_init(struct ast_private *ast)
 {
-	struct drm_device *dev = &ast->base;
 	size_t size, i;
-	struct drm_gem_vram_object *gbo;
 	void __iomem *vaddr;
-	int ret;
+	u64 offset;
 
 	size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
 
+	vaddr = ast->vram + ast->vram_fb_available;
+	offset = ast->vram_base + ast->vram_fb_available;
+
 	for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
-		gbo = drm_gem_vram_create(dev, size, 0);
-		if (IS_ERR(gbo)) {
-			ret = PTR_ERR(gbo);
-			goto err_drm_gem_vram_put;
-		}
-		ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
-					    DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
-		if (ret) {
-			drm_gem_vram_put(gbo);
-			goto err_drm_gem_vram_put;
-		}
-		vaddr = drm_gem_vram_vmap(gbo);
-		if (IS_ERR(vaddr)) {
-			ret = PTR_ERR(vaddr);
-			drm_gem_vram_unpin(gbo);
-			drm_gem_vram_put(gbo);
-			goto err_drm_gem_vram_put;
-		}
 
-		ast->cursor.gbo[i] = gbo;
-		ast->cursor.vaddr[i] = vaddr;
-	}
+		if (ast->vram_fb_available < size)
+			return -ENOMEM;
 
-	return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
+		vaddr -= size;
+		offset -= size;
 
-err_drm_gem_vram_put:
-	while (i) {
-		--i;
-		gbo = ast->cursor.gbo[i];
-		drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
-		drm_gem_vram_unpin(gbo);
-		drm_gem_vram_put(gbo);
+		ast->cursor.vaddr[i] = vaddr;
+		ast->cursor.offset[i] = offset;
+		ast->vram_fb_available -= size;
 	}
-	return ret;
+
+	return 0;
 }
 
 static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int height)
@@ -169,7 +129,6 @@ static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int h
 int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
 {
 	struct drm_device *dev = &ast->base;
-	struct drm_gem_vram_object *gbo;
 	int ret;
 	void *src;
 	void __iomem *dst;
@@ -178,15 +137,13 @@ int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
 	    drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
 		return -EINVAL;
 
-	gbo = drm_gem_vram_of_gem(fb->obj[0]);
-
-	ret = drm_gem_vram_pin(gbo, 0);
+	ret = drm_gem_shmem_pin(fb->obj[0]);
 	if (ret)
 		return ret;
-	src = drm_gem_vram_vmap(gbo);
+	src = drm_gem_shmem_vmap(fb->obj[0]);
 	if (IS_ERR(src)) {
 		ret = PTR_ERR(src);
-		goto err_drm_gem_vram_unpin;
+		goto err_drm_gem_shmem_unpin;
 	}
 
 	dst = ast->cursor.vaddr[ast->cursor.next_index];
@@ -194,13 +151,13 @@ int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
 	/* do data transfer to cursor BO */
 	update_cursor_image(dst, src, fb->width, fb->height);
 
-	drm_gem_vram_vunmap(gbo, src);
-	drm_gem_vram_unpin(gbo);
+	drm_gem_shmem_vunmap(fb->obj[0], src);
+	drm_gem_shmem_unpin(fb->obj[0]);
 
 	return 0;
 
-err_drm_gem_vram_unpin:
-	drm_gem_vram_unpin(gbo);
+err_drm_gem_shmem_unpin:
+	drm_gem_shmem_unpin(fb->obj[0]);
 	return ret;
 }
 
@@ -217,15 +174,7 @@ static void ast_cursor_set_base(struct ast_private *ast, u64 address)
 
 void ast_cursor_page_flip(struct ast_private *ast)
 {
-	struct drm_device *dev = &ast->base;
-	struct drm_gem_vram_object *gbo;
-	s64 off;
-
-	gbo = ast->cursor.gbo[ast->cursor.next_index];
-
-	off = drm_gem_vram_offset(gbo);
-	if (drm_WARN_ON_ONCE(dev, off < 0))
-		return; /* Bug: we didn't pin the cursor HW BO to VRAM. */
+	u64 off = ast->cursor.offset[ast->cursor.next_index];
 
 	ast_cursor_set_base(ast, off);
 
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index f0b4af1c390a..85748ef869d3 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -33,7 +33,7 @@
 #include <drm/drm_crtc_helper.h>
 #include <drm/drm_drv.h>
 #include <drm/drm_fb_helper.h>
-#include <drm/drm_gem_vram_helper.h>
+#include <drm/drm_gem_shmem_helper.h>
 #include <drm/drm_probe_helper.h>
 
 #include "ast_drv.h"
@@ -62,7 +62,8 @@ static struct drm_driver ast_driver = {
 	.minor = DRIVER_MINOR,
 	.patchlevel = DRIVER_PATCHLEVEL,
 
-	DRM_GEM_VRAM_DRIVER
+	.gem_create_object = drm_gem_shmem_create_object_cached,
+	DRM_GEM_SHMEM_DRIVER_OPS
 };
 
 /*
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 467049ca8430..d1fcbf7d8026 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -129,9 +129,15 @@ struct ast_private {
 
 	int fb_mtrr;
 
+	void __iomem	*vram;
+	unsigned long	vram_base;
+	unsigned long	vram_size;
+	unsigned long	vram_fb_available;
+
 	struct {
-		struct drm_gem_vram_object *gbo[AST_DEFAULT_HWC_NUM];
+		struct drm_gem_shmem_object *gbo[AST_DEFAULT_HWC_NUM];
 		void __iomem *vaddr[AST_DEFAULT_HWC_NUM];
+		u64 offset[AST_DEFAULT_HWC_NUM];
 		unsigned int next_index;
 	} cursor;
 
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 77066bca8793..2e905d827df8 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -32,7 +32,6 @@
 #include <drm/drm_crtc_helper.h>
 #include <drm/drm_drv.h>
 #include <drm/drm_gem.h>
-#include <drm/drm_gem_vram_helper.h>
 #include <drm/drm_managed.h>
 
 #include "ast_drv.h"
diff --git a/drivers/gpu/drm/ast/ast_mm.c b/drivers/gpu/drm/ast/ast_mm.c
index 8392ebde504b..6a5fbba52441 100644
--- a/drivers/gpu/drm/ast/ast_mm.c
+++ b/drivers/gpu/drm/ast/ast_mm.c
@@ -28,7 +28,6 @@
 
 #include <linux/pci.h>
 
-#include <drm/drm_gem_vram_helper.h>
 #include <drm/drm_managed.h>
 #include <drm/drm_print.h>
 
@@ -86,22 +85,33 @@ static void ast_mm_release(struct drm_device *dev, void *ptr)
 int ast_mm_init(struct ast_private *ast)
 {
 	struct drm_device *dev = &ast->base;
+	resource_size_t start, len;
 	u32 vram_size;
 	int ret;
 
-	vram_size = ast_get_vram_size(ast);
+	/* BAR 0 is VRAM */
+	start = pci_resource_start(dev->pdev, 0);
+	len = pci_resource_len(dev->pdev, 0);
+
+	arch_io_reserve_memtype_wc(start, len);
+	ast->fb_mtrr = arch_phys_wc_add(start, len);
 
-	ret = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
-				    vram_size);
-	if (ret) {
-		drm_err(dev, "Error initializing VRAM MM; %d\n", ret);
-		return ret;
+	ast->vram = ioremap(start, len);
+	if (!ast->vram) {
+		ret = -ENOMEM;
+		goto err_arch_phys_wc_del;
 	}
 
-	arch_io_reserve_memtype_wc(pci_resource_start(dev->pdev, 0),
-				   pci_resource_len(dev->pdev, 0));
-	ast->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev, 0),
-					pci_resource_len(dev->pdev, 0));
+	vram_size = ast_get_vram_size(ast);
+
+	ast->vram_base = start;
+	ast->vram_size = vram_size;
+	ast->vram_fb_available = vram_size;
 
 	return drmm_add_action_or_reset(dev, ast_mm_release, NULL);
+
+err_arch_phys_wc_del:
+	arch_phys_wc_del(ast->fb_mtrr);
+	arch_io_free_memtype_wc(start, len);
+	return ret;
 }
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 834a156e3a75..7e3293e56caa 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -36,9 +36,12 @@
 #include <drm/drm_atomic_state_helper.h>
 #include <drm/drm_crtc.h>
 #include <drm/drm_crtc_helper.h>
+#include <drm/drm_damage_helper.h>
+#include <drm/drm_format_helper.h>
 #include <drm/drm_fourcc.h>
 #include <drm/drm_gem_framebuffer_helper.h>
-#include <drm/drm_gem_vram_helper.h>
+#include <drm/drm_gem_shmem_helper.h>
+#include <drm/drm_managed.h>
 #include <drm/drm_plane_helper.h>
 #include <drm/drm_probe_helper.h>
 #include <drm/drm_simple_kms_helper.h>
@@ -563,6 +566,27 @@ static int ast_primary_plane_helper_atomic_check(struct drm_plane *plane,
 	return 0;
 }
 
+static void ast_handle_damage(struct ast_private *ast,
+			      struct drm_framebuffer *fb,
+			      struct drm_rect *clip)
+{
+	struct drm_device *dev = &ast->base;
+	void *vmap;
+
+	vmap = drm_gem_shmem_vmap(fb->obj[0]);
+	if (drm_WARN_ON(dev, !vmap))
+		return; /* BUG: SHMEM BO should always be vmapped */
+
+	drm_fb_memcpy_dstclip(ast->vram, vmap, fb, clip);
+
+	drm_gem_shmem_vunmap(fb->obj[0], vmap);
+
+	ast_set_offset_reg(ast, fb);
+	ast_set_start_address_crt1(ast, (u32)0);
+
+	ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0x00);
+}
+
 static void
 ast_primary_plane_helper_atomic_update(struct drm_plane *plane,
 				       struct drm_plane_state *old_state)
@@ -570,10 +594,12 @@ ast_primary_plane_helper_atomic_update(struct drm_plane *plane,
 	struct drm_device *dev = plane->dev;
 	struct ast_private *ast = to_ast_private(dev);
 	struct drm_plane_state *state = plane->state;
-	struct drm_gem_vram_object *gbo;
-	s64 gpu_addr;
 	struct drm_framebuffer *fb = state->fb;
 	struct drm_framebuffer *old_fb = old_state->fb;
+	struct drm_rect damage;
+
+	if (!fb)
+		return;
 
 	if (!old_fb || (fb->format != old_fb->format)) {
 		struct drm_crtc_state *crtc_state = state->crtc->state;
@@ -584,15 +610,8 @@ ast_primary_plane_helper_atomic_update(struct drm_plane *plane,
 		ast_set_vbios_color_reg(ast, fb->format, vbios_mode_info);
 	}
 
-	gbo = drm_gem_vram_of_gem(fb->obj[0]);
-	gpu_addr = drm_gem_vram_offset(gbo);
-	if (drm_WARN_ON_ONCE(dev, gpu_addr < 0))
-		return; /* Bug: we didn't pin the BO to VRAM in prepare_fb. */
-
-	ast_set_offset_reg(ast, fb);
-	ast_set_start_address_crt1(ast, (u32)gpu_addr);
-
-	ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0x00);
+	if (drm_atomic_helper_damage_merged(old_state, state, &damage))
+		ast_handle_damage(ast, fb, &damage);
 }
 
 static void
@@ -605,8 +624,7 @@ ast_primary_plane_helper_atomic_disable(struct drm_plane *plane,
 }
 
 static const struct drm_plane_helper_funcs ast_primary_plane_helper_funcs = {
-	.prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
-	.cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
+	.prepare_fb = drm_gem_fb_prepare_fb,
 	.atomic_check = ast_primary_plane_helper_atomic_check,
 	.atomic_update = ast_primary_plane_helper_atomic_update,
 	.atomic_disable = ast_primary_plane_helper_atomic_disable,
@@ -641,6 +659,10 @@ ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
 	if (!crtc || !fb)
 		return 0;
 
+	ret = drm_gem_fb_prepare_fb(plane, new_state);
+	if (ret)
+		return ret;
+
 	ast = to_ast_private(plane->dev);
 
 	ret = ast_cursor_blit(ast, fb);
@@ -1073,9 +1095,28 @@ ast_mode_config_helper_funcs = {
 	.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
 };
 
+static enum drm_mode_status
+ast_mode_config_mode_valid(struct drm_device *dev,
+			   const struct drm_display_mode *mode)
+{
+	static const unsigned long max_bpp = 4; /* DRM_FORMAT_XRGB8888 */
+	struct ast_private *ast = to_ast_private(dev);
+	unsigned long fbsize, fbpages, max_fbpages;
+
+	max_fbpages = (ast->vram_size) >> PAGE_SHIFT;
+
+	fbsize = mode->hdisplay * mode->vdisplay * max_bpp;
+	fbpages = DIV_ROUND_UP(fbsize, PAGE_SIZE);
+
+	if (fbpages > max_fbpages)
+		return MODE_MEM;
+
+	return MODE_OK;
+}
+
 static const struct drm_mode_config_funcs ast_mode_config_funcs = {
-	.fb_create = drm_gem_fb_create,
-	.mode_valid = drm_vram_helper_mode_valid,
+	.fb_create = drm_gem_fb_create_with_dirty,
+	.mode_valid = ast_mode_config_mode_valid,
 	.atomic_check = drm_atomic_helper_check,
 	.atomic_commit = drm_atomic_helper_commit,
 };
@@ -1097,7 +1138,7 @@ int ast_mode_config_init(struct ast_private *ast)
 	dev->mode_config.min_width = 0;
 	dev->mode_config.min_height = 0;
 	dev->mode_config.preferred_depth = 24;
-	dev->mode_config.prefer_shadow = 1;
+	dev->mode_config.prefer_shadow = 0;
 	dev->mode_config.fb_base = pci_resource_start(dev->pdev, 0);
 
 	if (ast->chip == AST2100 ||
-- 
2.28.0


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2698 bytes --]

Hi,

Yes, I can build custom kernels and test but I won't have time for that 
before the end of September so I'll do it only then.

And thanks a lot :-).

-- 
 i.


On Thu, 17 Sep 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.
> 
> Are you able to build and run a test kernel?
> 
> I'm seriously considering moving ast to the SHMEM memory manager, which
> would restore the higher resolutions.
> 
> If you're able to test, you need the git tree drm-tip/drm-tip and the
> attached patch.
> 
> Alternatively, I've pushed all to
> 
>   https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/ast-shmem
> 
> You'd have to checkout the tree and switch to the ast-shmem branch.
> 
> Please report back if that solves the issue for you.
> 
> Best regards
> Thomas
> 
> > 
> > With 5.6.16:
> > 
> > $ xrandr
> > Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 2048
> > VGA-1 connected primary 1600x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
> >    1600x1200     60.00* 
> >    1680x1050     59.95  
> >    1280x1024     75.02    60.02  
> >    1440x900      59.89  
> >    1280x800      59.81  
> >    1024x768      75.03    60.00  
> >    800x600       75.00    60.32  
> >    640x480       75.00    59.94  
> >    1920x1200_60.0  59.95  
> > 
> > If I try to change to that manually added high-res mode, I get:
> > xrandr: Configure crtc 0 failed
> > 
> > With 5.3 series I've this:
> > 
> > Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 2048
> > VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
> >    1920x1200     59.95*+
> >    1600x1200     60.00  
> >    1680x1050     59.95  
> >    1280x1024     75.02    60.02  
> >    1440x900      59.89  
> >    1280x800      59.81  
> >    1024x768      75.03    60.00  
> >    800x600       75.00    60.32  
> >    640x480       75.00    59.94  
> >    1920x1200_60.0  59.95  
> > 
> > As I've had issues in getting EDID reliably from the monitor, I provide it 
> > on kernel command-line (the one dumped from the monitor I use). In 
> > addition, I've another workaround for past issues related to EDID which 
> > always adds that 1920x1200_60.0 mode but now I cannot use even it to
> > enter a high-res mode.
> > 
> > If you need some additional info or want me to test a patch, just let me 
> > know (but some delay is expected in testing patches). Thanks.
> > 
> > 
> 
>

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 482 bytes --]

Hi

Am 17.09.20 um 13:17 schrieb Ilpo Järvinen:
> Hi,
> 
> Yes, I can build custom kernels and test but I won't have time for that 
> before the end of September so I'll do it only then.

No problem, that's still fine.

Best regards
Thomas

> 
> And thanks a lot :-).
> 

-- 
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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

On Thu, 17 Sep 2020, Thomas Zimmermann wrote:

> Hi
> 
> Am 17.09.20 um 13:17 schrieb Ilpo Järvinen:
> > Hi,
> > 
> > Yes, I can build custom kernels and test but I won't have time for that 
> > before the end of September so I'll do it only then.
> 
> No problem, that's still fine.
> 
> Best regards
> Thomas
> 
> > 
> > And thanks a lot :-).
> > 

The high-res mode works, however, I wasn't expecting it to be this slow 
though as I can see the slowish sweeps to redraw the screen or large parts 
of it. Maybe you meant all along this slow (I was expecting something like 
memcpy slow and this looks definitely much slower)?

While a large redrawing operation is going on, mouse cursor stops moving 
normally until it is over and it then jumps to catch up. When the mouse is 
over something that doesn't require large redraw, it seems to work quite 
normally.

-- 
 i.

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thomas Zimmermann]

Hi

On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen"
<ilpo.jarvinen@cs.helsinki.fi> wrote:

> On Thu, 17 Sep 2020, Thomas Zimmermann wrote:
> 
> > Hi
> > 
> > Am 17.09.20 um 13:17 schrieb Ilpo Järvinen:
> > > Hi,
> > > 
> > > Yes, I can build custom kernels and test but I won't have time for that 
> > > before the end of September so I'll do it only then.
> > 
> > No problem, that's still fine.
> > 
> > Best regards
> > Thomas
> > 
> > > 
> > > And thanks a lot :-).
> > > 
> 
> The high-res mode works, however, I wasn't expecting it to be this slow 
> though as I can see the slowish sweeps to redraw the screen or large parts 
> of it. Maybe you meant all along this slow (I was expecting something like 
> memcpy slow and this looks definitely much slower)?

First of all, thanks for testing. I didn't expect it to be that slow either.

> 
> While a large redrawing operation is going on, mouse cursor stops moving 
> normally until it is over and it then jumps to catch up. When the mouse is 
> over something that doesn't require large redraw, it seems to work quite 
> normally.
> 

That sounds bad. The cursor is drawn by hardware, so I'd expect it to move
smoothly across the screen. Maybe the position update is blocked from the
framebuffer's memcpy within the kernel code.

I was hoping the performance would be acceptable, but this sounds like a
dealbreaker to me. I can look a bit closer if there are issues/bugs in the
code that make it run slow. Not holding my breath for it though...

Best regards
Thomas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]

On Wed, 14 Oct 2020, Thomas Zimmermann wrote:
> On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen"
> <ilpo.jarvinen@cs.helsinki.fi> wrote:
> 
> > The high-res mode works, however, I wasn't expecting it to be this slow 
> > though as I can see the slowish sweeps to redraw the screen or large parts 
> > of it. Maybe you meant all along this slow (I was expecting something like 
> > memcpy slow and this looks definitely much slower)?
> 
> First of all, thanks for testing. I didn't expect it to be that slow either.
> 
> > 
> > While a large redrawing operation is going on, mouse cursor stops moving 
> > normally until it is over and it then jumps to catch up. When the mouse is 
> > over something that doesn't require large redraw, it seems to work quite 
> > normally.
> > 
> 
> That sounds bad. The cursor is drawn by hardware, so I'd expect it to move
> smoothly across the screen. Maybe the position update is blocked from the
> framebuffer's memcpy within the kernel code.
> 
> I was hoping the performance would be acceptable, but this sounds like a
> dealbreaker to me. I can look a bit closer if there are issues/bugs in the
> code that make it run slow. Not holding my breath for it though...

Yeah, with like 5fps with full redraw it's not really acceptable (it's a 
bit hard to estimate exactly but certainly less than 10fps). Writing to 
video mem / normally working memcpy itself really cannot be this slow as 
it would impact fps in non-shmem case too I think.

Also, there's more into this. I noticed that after using this kernel,
I cannot boot normally neither warm nor even cold boot after poweroff 
(POST is slower than usual, beeps one less and gets stuck, I didn't 
manage to switch into textual POST messages to see if there's any info as 
the tab key for swithing got also broken). Sadly those beeps don't match 
to the motherboard manual in ok nor broken case so I've no idea what they 
mean and whether the beeps really related to POST or e.g. from graphics 
init.

Only after cutting power entirely from the machine, the boot again 
succeeds. To me those symptoms sounds like it somehow managed to break 
something related to IPMI because IPMI is reinitialized only if I remove 
the power. If I've understood correctly IPMI is somehow connected to 
graphics side within the AST.

I haven't yet tested with the plain 5.9-rc5 to rule out it breaking 
the boot (but I find it less likely to be case here).


-- 
 i.

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Thomas Zimmermann]

Hi

On Thu, 15 Oct 2020 11:10:48 +0300 (EEST) "Ilpo Järvinen"
<ilpo.jarvinen@cs.helsinki.fi> wrote:

> On Wed, 14 Oct 2020, Thomas Zimmermann wrote:
> > On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen"
> > <ilpo.jarvinen@cs.helsinki.fi> wrote:
> > 
> > > The high-res mode works, however, I wasn't expecting it to be this slow 
> > > though as I can see the slowish sweeps to redraw the screen or large
> > > parts of it. Maybe you meant all along this slow (I was expecting
> > > something like memcpy slow and this looks definitely much slower)?
> > 
> > First of all, thanks for testing. I didn't expect it to be that slow
> > either.
> > 
> > > 
> > > While a large redrawing operation is going on, mouse cursor stops
> > > moving normally until it is over and it then jumps to catch up. When
> > > the mouse is over something that doesn't require large redraw, it seems
> > > to work quite normally.
> > > 
> > 
> > That sounds bad. The cursor is drawn by hardware, so I'd expect it to move
> > smoothly across the screen. Maybe the position update is blocked from the
> > framebuffer's memcpy within the kernel code.
> > 
> > I was hoping the performance would be acceptable, but this sounds like a
> > dealbreaker to me. I can look a bit closer if there are issues/bugs in the
> > code that make it run slow. Not holding my breath for it though...
> 
> Yeah, with like 5fps with full redraw it's not really acceptable (it's a 
> bit hard to estimate exactly but certainly less than 10fps). Writing to 
> video mem / normally working memcpy itself really cannot be this slow as 
> it would impact fps in non-shmem case too I think.

I guess you run X for testing? In the current upstream kernel, X11 should use
an internal shadow buffer to compose the displayed image; and then do it's own
memcpy into video RAM.

If you go to a lower resolution is the performance similar to the
current upstream kernel?

> 
> Also, there's more into this. I noticed that after using this kernel,
> I cannot boot normally neither warm nor even cold boot after poweroff 
> (POST is slower than usual, beeps one less and gets stuck, I didn't 
> manage to switch into textual POST messages to see if there's any info as 
> the tab key for swithing got also broken). Sadly those beeps don't match 
> to the motherboard manual in ok nor broken case so I've no idea what they 
> mean and whether the beeps really related to POST or e.g. from graphics 
> init.
> 
> Only after cutting power entirely from the machine, the boot again 
> succeeds. To me those symptoms sounds like it somehow managed to break 
> something related to IPMI because IPMI is reinitialized only if I remove 
> the power. If I've understood correctly IPMI is somehow connected to 
> graphics side within the AST.

The AST chip does all kinds of things. It's hard to say if it's related.

> 
> I haven't yet tested with the plain 5.9-rc5 to rule out it breaking 
> the boot (but I find it less likely to be case here).
> 
> 

I can rebase the patch onto a more recent upstream kernel and send out an
update.

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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 3661 bytes --]

On Thu, 15 Oct 2020, Thomas Zimmermann wrote:
> On Thu, 15 Oct 2020 11:10:48 +0300 (EEST) "Ilpo Järvinen"
> <ilpo.jarvinen@cs.helsinki.fi> wrote:
> > On Wed, 14 Oct 2020, Thomas Zimmermann wrote:
> > > On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen"
> > > <ilpo.jarvinen@cs.helsinki.fi> wrote:
> > > > While a large redrawing operation is going on, mouse cursor stops
> > > > moving normally until it is over and it then jumps to catch up. When
> > > > the mouse is over something that doesn't require large redraw, it seems
> > > > to work quite normally.
> > > > 
> > > 
> > > That sounds bad. The cursor is drawn by hardware, so I'd expect it to move
> > > smoothly across the screen. Maybe the position update is blocked from the
> > > framebuffer's memcpy within the kernel code.
> > > 
> > > I was hoping the performance would be acceptable, but this sounds like a
> > > dealbreaker to me. I can look a bit closer if there are issues/bugs in the
> > > code that make it run slow. Not holding my breath for it though...
> > 
> > Yeah, with like 5fps with full redraw it's not really acceptable (it's a 
> > bit hard to estimate exactly but certainly less than 10fps). Writing to 
> > video mem / normally working memcpy itself really cannot be this slow as 
> > it would impact fps in non-shmem case too I think.
> 
> I guess you run X for testing? In the current upstream kernel, X11 should use
> an internal shadow buffer to compose the displayed image; and then do it's own
> memcpy into video RAM.

Yes I run X, however, the slow redraws are already visible during boot
up with the text console. It very noticeable while the text "scrolls" 
(=slowly redraws) with 4-10fps.

I picked up that shadow buffer difference related while comparing the X 
log files. When I noticed that I was even considering whether to test also 
with that "extra" shadow buffer to see if it helps any but discarded the 
idea as I cannot really see how it would help.

My point was that also in the upstream case there's memcpy from the shadow 
buffer to video RAM which cannot be as slow as the copying now in shmem 
case because it would also fail to reach normal fps.

> If you go to a lower resolution is the performance similar to the
> current upstream kernel?

I'll try to remember to do that once I boot next time.

> > Also, there's more into this. I noticed that after using this kernel,
> > I cannot boot normally neither warm nor even cold boot after poweroff 
> > (POST is slower than usual, beeps one less and gets stuck, I didn't 
> > manage to switch into textual POST messages to see if there's any info as 
> > the tab key for swithing got also broken). Sadly those beeps don't match 
> > to the motherboard manual in ok nor broken case so I've no idea what they 
> > mean and whether the beeps really related to POST or e.g. from graphics 
> > init.
> > 
> > Only after cutting power entirely from the machine, the boot again 
> > succeeds. To me those symptoms sounds like it somehow managed to break 
> > something related to IPMI because IPMI is reinitialized only if I remove 
> > the power. If I've understood correctly IPMI is somehow connected to 
> > graphics side within the AST.
> 
> The AST chip does all kinds of things. It's hard to say if it's related.
> 
> > 
> > I haven't yet tested with the plain 5.9-rc5 to rule out it breaking 
> > the boot (but I find it less likely to be case here).
> > 
> > 
> 
> I can rebase the patch onto a more recent upstream kernel and send out an
> update.

It's actually a bit more work for me to change the base.

-- 
 i.

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel