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.
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.
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?
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
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
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
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:
- dpms off
- allocate big buffer
- 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
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:
- dpms off
- allocate big buffer
- 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.
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.
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 :-).
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 :-).
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.
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
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).
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
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.
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Ilpo Järvinen -
Thomas Zimmermann