[SLOF] [PATCH 0/4] Accelerate the screen drawing functions

[Nikunj A Dadhania]

Thomas Huth <thuth at redhat.com> writes:

> While working on the cursor drawing issues, I've noticed that
> some other functions in the framebuffer code of SLOF could be
> accelerated quite a bit. The first two patches are rather
> cosmetic and do not contribute much to the speed improvement,
> but the last two patches speed up the drawing quite a lot!
>
> There are two core functions, MRMOVE and RFILL, which are used
> by the drawing functions to write to the framebuffer and which
> were not really adapted to the KVMPPC_H_LOGICAL_MEMOP of
> board-qemu yet (i.e. they were written with js2x in mind).
> So they both triggered a hypercall for every 8-byte access
> to the framebuffer instead of handling larger transfers at
> once. By implementing a proper accelerated version of these
> calls, the text drawing and screen-erasing can be speed-up
> quite a bit:
>
> - Fixing MRMOVE improves the character drawing by factor 2
>   or more (the "benchmark" that I've published in my
>   cover-letter of the cursor-improvement series earlier
>   this week now only takes 0.3 s instead of 0.8 s!)
>
> - Fixing RFILL improves the screen erasing function by
>   factor 10 or even more! The function "erase-screen"
>   took approx. 1.3 s before the fix, and now only takes
>   0.1 s after the fix.
>
> Both fixes also speed up grub in graphical mode quite a bit,
> since grub apparently uses the firmware to erase the screen.

Thanks, the drawing is really fast now in vnc and grub edit screen.


> Something to consider: In the RFILL patch, I am first filling
> a temporary buffer with the pattern and then using this
> buffer as a parameter to the KVMPPC_H_LOGICAL_MEMOP copy
> function (i.e. by calling the _FASTMRMOVE macro). We could
> also extend the KVMPPC_H_LOGICAL_MEMOP to directly provide
> a "memset" sub-function instead. This could result in some
> more few percents of speed improvement, but I am not sure
> whether this is still worth the effort and circumstances
> (newer SLOF versions would not be compatible with older
> versions of QEMU anymore). What do you think?

Current default buffer size of 512 bytes seems reasonable and not worth
the effort.

>
> Thomas Huth (4):
>   terminal: Disable the terminal-write trace by default
>   fbuffer: Precalculate line length in bytes
>   fbuffer: Implement MRMOVE as an accelerated primitive
>   fbuffer: Implement RFILL as an accelerated primitive

Tested-by: Nikunj A Dadhania <nikunj at linux.vnet.ibm.com>

Regards
Nikunj