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

[Ilpo Järvinen]

On Thu, 15 Oct 2020, Thomas Zimmermann wrote:
> On Thu, 15 Oct 2020 11:10:48 +0300 (EEST) "Ilpo Järvinen"
> <ilpo.jarvinen at 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 at 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.