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