I took another look at the root cause and it seems that the excessive
slowness in emulator stems specifically from writing to framebuffer
memory, since modifying the code to write to normal memory seems not to
exhibit the slowdown.
Interesting observation. That is definitively worth investigating further.
My hypothesis is that QEMU updates the display
window on every write to that memory, which would explain the
performance hit.
Last time I've checked the QEMU sources (and assuming I've understood it
correctly :)), it should blit the damaged part of the emulated
framebuffer at 60 Hz (the damage tracking is, of course, not helping
much during scrolling).
But maybe you are hitting some degraded mode of operation. Depending on
the precision of the damage tracking, blitting on every framebuffer
update might indeed pose a huge overhead.
On real hardware, those memory accesses would still be
slower than normal memory, as they would be backed by video ram, but
probably nowhere near how bad it is in QEMU.
Agreed.
Sadly, I can't think of a
way how to make this faster without adding a proper driver for the
emulated video card to the kernel
I don't think that this is a correct conclusion. Like I have written in
my previous email, it is obviously possible that the drawing routines in
the HelenOS kernel are currently suboptimal. It is possible that we map
the framebuffer memory with some suboptimal attributes (which disable
some optimization in QEMU) or that we do some other stupid mistake.
You have observed that the problem is the interaction with QEMU. If this
is a case of QEMU configuration, then an accelerated driver or any
blitting code optimization on the HelenOS side might not help at all if
the performance is wasted by the QEMU blitting the framebuffer too
often. Try to find the root cause there.
Many times, I've run non-accelerated graphics output in QEMU under
emulation (the Linux console, Windows with the non-accelerated SVGA
driver, Wayland with the LLVMpipe backend) and while it is surely very
far from being fast, it is still usable.
Just to get some rough idea, I've just run the same benchmark as before
with the Linux console in QEMU under emulation. It was indeed about 9.7
times slower compared to bare metal (some 850 lines per second). Not
great if the workload would be mostly scrolling output. Somewhat
noticeable slowdown for the usual boot. But surely not an unbearable
bottleneck.
Finally, the same benchmark in QEMU under KVM is only about 2 % slower
compared to bare metal. So clearly QEMU itself can perform very
reasonably (when running on an accelerated GPU backend).
A compromise fix could be to add the
option to turn scrolling into "rolling" instead, where newest line would
wrap around to the top of screen instead of shifting the entire screen
contents.
I suggest you try to implement the half-page scrolling first. That
should reduce the amount of scrolling by a factor of n / 2 (where n is
the number of horizontal text lines) while still feeling somewhat natural.
M.D.
_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
