Hi On Thu, 15 Oct 2020 11:10:48 +0300 (EEST) "Ilpo Järvinen" <ilpo.jarvinen@xxxxxxxxxxxxxx> wrote: > On Wed, 14 Oct 2020, Thomas Zimmermann wrote: > > On Wed, 14 Oct 2020 09:58:37 +0300 (EEST) "Ilpo Järvinen" > > <ilpo.jarvinen@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
