From: Greg Kurz <hidden> Date: 2015-05-27 00:11:23
SLOF currently calls hv-logical-load and hv-logical-store for every pixel
when enabling or disabling the cursor. This is suboptimal when writing one
char at a time to the console since terminal-write always toggles the cursor.
And this is precisely what grub is doing when the user wants to edit a menu
entry... the result is an incredibly slow and barely usable interface.
The inner loop in fb8-toggle-cursor handles a contiguous region: it can be
converted to hv-logical-memop. The result is 32 times less hcalls per char
and a serious improvement in grub usability.
Signed-off-by: Greg Kurz <redacted>
---
slof/fs/fbuffer.fs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Nikunj A Dadhania <hidden> Date: 2015-05-27 05:11:17
Greg Kurz [off-list ref] writes:
quoted hunk
SLOF currently calls hv-logical-load and hv-logical-store for every pixel
when enabling or disabling the cursor. This is suboptimal when writing one
char at a time to the console since terminal-write always toggles the cursor.
And this is precisely what grub is doing when the user wants to edit a menu
entry... the result is an incredibly slow and barely usable interface.
The inner loop in fb8-toggle-cursor handles a contiguous region: it can be
converted to hv-logical-memop. The result is 32 times less hcalls per char
and a serious improvement in grub usability.
Signed-off-by: Greg Kurz <redacted>
---
slof/fs/fbuffer.fs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Thomas Huth <hidden> Date: 2015-05-27 05:59:50
On Wed, 27 May 2015 02:11:13 +0200
Greg Kurz [off-list ref] wrote:
SLOF currently calls hv-logical-load and hv-logical-store for every pixel
when enabling or disabling the cursor. This is suboptimal when writing one
char at a time to the console since terminal-write always toggles the cursor.
And this is precisely what grub is doing when the user wants to edit a menu
entry... the result is an incredibly slow and barely usable interface.
The inner loop in fb8-toggle-cursor handles a contiguous region: it can be
converted to hv-logical-memop. The result is 32 times less hcalls per char
and a serious improvement in grub usability.
If you use hv-logical-memop in this file here, you definitely break
board-js2x, since this is bare metal and hv-logical-memop is not
defined there.
I think you should either move the new function to board-qemu and handle
it there like it is done for hcall-invert-screen already, or we could
think of introducing a helper function that is defined by each board
which does the xor operation on a memory region (that way we could
maybe also unify hcall-invert-screen and fb8-invert-screen again).
Thomas
From: Greg Kurz <hidden> Date: 2015-05-27 09:01:47
On Wed, 27 May 2015 10:41:06 +0530
Nikunj A Dadhania [off-list ref] wrote:
Greg Kurz [off-list ref] writes:
quoted
SLOF currently calls hv-logical-load and hv-logical-store for every pixel
when enabling or disabling the cursor. This is suboptimal when writing one
char at a time to the console since terminal-write always toggles the cursor.
And this is precisely what grub is doing when the user wants to edit a menu
entry... the result is an incredibly slow and barely usable interface.
The inner loop in fb8-toggle-cursor handles a contiguous region: it can be
converted to hv-logical-memop. The result is 32 times less hcalls per char
and a serious improvement in grub usability.
Signed-off-by: Greg Kurz <redacted>
---
slof/fs/fbuffer.fs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Why did you drop "char-width screen-depth * -" in the new code? This is
not me mentioned in the description.
This is because the current inner loop increments the address. When the loop
ends, we're pointing at the next char, that is char-width * screen-depth bytes
too far.
In the new code, the address is duped on the stack before calling hv-logical-memop,
so we don't need to fix it when proceeding to next line.
In my first attempt, I forgot to drop the subtraction and got an interesting
visual result :)
From: Nikunj A Dadhania <hidden> Date: 2015-05-27 09:22:14
Greg Kurz [off-list ref] writes:
On Wed, 27 May 2015 10:41:06 +0530
Nikunj A Dadhania [off-list ref] wrote:
quoted
Greg Kurz [off-list ref] writes:
quoted
SLOF currently calls hv-logical-load and hv-logical-store for every pixel
when enabling or disabling the cursor. This is suboptimal when writing one
char at a time to the console since terminal-write always toggles the cursor.
And this is precisely what grub is doing when the user wants to edit a menu
entry... the result is an incredibly slow and barely usable interface.
The inner loop in fb8-toggle-cursor handles a contiguous region: it can be
converted to hv-logical-memop. The result is 32 times less hcalls per char
and a serious improvement in grub usability.
Signed-off-by: Greg Kurz <redacted>
---
slof/fs/fbuffer.fs | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Why did you drop "char-width screen-depth * -" in the new code? This is
not me mentioned in the description.
This is because the current inner loop increments the address. When the loop
ends, we're pointing at the next char, that is char-width * screen-depth bytes
too far.
In the new code, the address is duped on the stack before calling hv-logical-memop,
so we don't need to fix it when proceeding to next line.
Ah ok, i missed that 1+ in the loop.
In my first attempt, I forgot to drop the subtraction and got an interesting
visual result :)
From: Greg Kurz <hidden> Date: 2015-05-27 09:25:03
On Wed, 27 May 2015 07:59:34 +0200
Thomas Huth [off-list ref] wrote:
On Wed, 27 May 2015 02:11:13 +0200
Greg Kurz [off-list ref] wrote:
quoted
SLOF currently calls hv-logical-load and hv-logical-store for every pixel
when enabling or disabling the cursor. This is suboptimal when writing one
char at a time to the console since terminal-write always toggles the cursor.
And this is precisely what grub is doing when the user wants to edit a menu
entry... the result is an incredibly slow and barely usable interface.
The inner loop in fb8-toggle-cursor handles a contiguous region: it can be
converted to hv-logical-memop. The result is 32 times less hcalls per char
and a serious improvement in grub usability.
Good idea for an optimization!
Heh no big deal... the hardest part was to find that the LOAD/STORE avalanche
was coming from these rb@ and rb! words. SLOF is still a mysterious beast to
me :)
If you use hv-logical-memop in this file here, you definitely break
board-js2x, since this is bare metal and hv-logical-memop is not
defined there.
Of course, this is common code... I'll remember for next time. :)
I think you should either move the new function to board-qemu and handle
it there like it is done for hcall-invert-screen already, or we could
think of introducing a helper function that is defined by each board
which does the xor operation on a memory region (that way we could
maybe also unify hcall-invert-screen and fb8-invert-screen again).
I guess the first proposal is the obvious fix. From there, we can
work out a patchset for the second proposal.