How do you handle ncpu greater than the number of Beasties that fit on a row?

In D2181#3, @emaste wrote:

How do you handle ncpu greater than the number of Beasties that fit on a row?

They are truncated at the edge of the row. See vtterm_draw_beasties around line 384:

ncpu = MIN(ncpu, vd->vd_width / vt_beastie_width);

In D2181#3, @emaste wrote:

How do you handle ncpu greater than the number of Beasties that fit on a row?

E.g. here is a video configured with the Orb graphic, with ncpus overridden to sixteen:
https://www.youtube.com/watch?v=MOMDSnk_1kE

Before i915kms loads, they are truncated at eight. After it loads, you can see all sixteen. Yes, this could be improved for ThunderX.

This is really cool!

Ping. What can I do to help move this forward?

I think one of the important things to do is to keep vt(4) simple. syscons(4) became so complex that nobody really understood how it worked anymore. I am afraid that patches that add gimmicks like these negatively affect the overall readability of vt(4) for little functional gain.

That said, I wouldn't mind seeing features like these added as long as they are separate from files like vt_core.c itself. Maybe we need a more generic interface for registering boot splashes/window borders/decorations/etc.

Thoughts?

In D2181#10, @ed wrote:

I think one of the important things to do is to keep vt(4) simple. syscons(4) became so complex that nobody really understood how it worked anymore. I am afraid that patches that add gimmicks like these negatively affect the overall readability of vt(4) for little functional gain.

If you've looked at the patch, there's very little change to existing code paths. I don't think it significantly affects readability at all.

That said, I wouldn't mind seeing features like these added as long as they are separate from files like vt_core.c itself. Maybe we need a more generic interface for registering boot splashes/window borders/decorations/etc.

It would not be hard to rework the vt integration slightly, as you suggest; have the beasties logic reserve some border area and the vt code draw inside the border.

Thoughts?

To incorrectly paraphrase Knuth, I think premature generalization is some sort of evil. We don't want too much abstraction. But it would not be hard to move (most) of this to another source file and make the hooks slightly more general.

Hi,

This is a really slow way of drawing things. We should finally (!) put an image blitter method in that takes a colour bitmap and draws it using the most efficient method possible.

For VGA, it's not efficient to do 8 RMW passes for each pixel being plotted. That may be fine in a VM and maybe for beastie, but it's not good enough for a general "draw image here" thing (eg splash screen.)

So I like this as a cute hack, but i'd be even happier if we finally un-mucked the VT layer:

• there should be a way to translate VT colours to hardware colours. Not everything is 16 colour VGA;
• there should be an image blit routine that isn't black-and-white - ie, it takes an array of pixel data and transparency data, and writes that out. for VGA it'll be the most efficient way of doing the planar access we need.
• it's likely that all the VT routines for font rendering, etc should not being using the 4 bit VT colour, but should at least have the option of 8 bit VGA, 16 bit RGB, etc. Right now we can't even do > 16 colour terminals, which is silly.

In D2181#12, @adrian wrote:

This is a really slow way of drawing things.

Sort of...

We should finally (!) put an image blitter method in that takes a colour bitmap and draws it using the most efficient method possible.

There is something like this — there is a vd_bitblt_bitmap() method. I initially used it, however I found that whatever driver is used by default ignored the mask argument. Every layer thus erased every layer below it, ruining the effect. In practice, we only ever draw once or twice (we do *not* have to redraw when the text draws or scrolls, for example — only when the resolution changes or we load a new kms driver) and it's plenty fast enough (faster than the human eye).

For VGA, it's not efficient to do 8 RMW passes for each pixel being plotted. That may be fine in a VM and maybe for beastie, but it's not good enough for a general "draw image here" thing (eg splash screen.)

It's plenty good enough for a splash screen, as far as I can tell. Of course, something that takes a larger bitmap would be nicer. If you want to go and fix every driver's vd_bitblt_bitmap method, I'd appreciate it :-).

So I like this as a cute hack, but i'd be even happier if we finally un-mucked the VT layer:

• there should be a way to translate VT colours to hardware colours. Not everything is 16 colour VGA;
• there should be an image blit routine that isn't black-and-white - ie, it takes an array of pixel data and transparency data, and writes that out. for VGA it'll be the most efficient way of doing the planar access we need.

vd_bitblt_bitmap. It just doesn't handle transparency correctly.

• it's likely that all the VT routines for font rendering, etc should not being using the 4 bit VT colour, but should at least have the option of 8 bit VGA, 16 bit RGB, etc. Right now we can't even do > 16 colour terminals, which is silly.

Yeah, agreed.

Again, the problem with the bitmap blit function is that it's only for one colour at a time. That's terrible for doing large scale image drawing, but fine for doing font glyph rendering.

So yeah, we really should overhaul the VT interface for doing colour management and blitting before we continue. :)

In D2181#14, @adrian wrote:

So yeah, we really should overhaul the VT interface for doing colour management and blitting before we continue. :)

Though I agree the blitting in vt(4) is far from optimal, is it really the case that the current code is unsuitable for the amount of image drawing we do right now? These images are only drawn once during boot and likely already disappear before the user starts to switch virtual terminals. In other words, the images only get drawn once.

Should this work really block on reimplementing the blitting?

Real VGA drawing is terribly slow. If we wanted to do any kind of splash screen animation then yes, you'll want to have real image drawing implemented in vt.

It's also terrible for colour maps - trying to make a /nice/ splash screen using the default 16 colour palette is very unfun.

This feature is really cool!

I agree with Ed: vt_core.c is already large and this new code should go to a separate file; IMHO, the splash screen code should be moved as well but that is a different topic.

Furthermore, I would not use the name "beastie" in function and variable names because it could be anything (like the orb).

One question: would it make sense to unify the current splash screen code and the per-CPU logo code? In other word, configure an area for the text (possibly the whole screen if there is nothing to draw, or no area at all if the splash screen takes the whole surface) and draw whatever we want on the remaining space? I feel the splash screen and the per-CPU features are really close.

In D2181#43862, @dumbbell wrote:

This feature is really cool!

Thanks!

I agree with Ed: vt_core.c is already large and this new code should go to a separate file; IMHO, the splash screen code should be moved as well but that is a different topic.

Ok.

Furthermore, I would not use the name "beastie" in function and variable names because it could be anything (like the orb).

Ok.

One question: would it make sense to unify the current splash screen code and the per-CPU logo code? In other word, configure an area for the text (possibly the whole screen if there is nothing to draw, or no area at all if the splash screen takes the whole surface) and draw whatever we want on the remaining space? I feel the splash screen and the per-CPU features are really close.

The current splash screen draws over the entire screen and then removes itself after a few seconds. I don't recall what the text drawing stuff is doing at that time. I guess it's similar behavior ("reserve this much screen area for graphics stuff, draw this stuff, erase it after N seconds").

Hi Conrad!

Sorry for not getting back to you, I still had no time to test your patch :-(

I have one question about EVT_SYSCTL_INT. Other than that, I see nothing wrong, but again, I didn't try it yet.

Thanks for taking another look. I appreciate it!

This looks good to me modulo some style nits and the question about the sysctls. I'm completely unfamiliar with vt though, so one of the other reviewers should ok this before committing.

The new tunables should also be documented in vt(4), but that can be done in a separate review/commit if you like.