stand: Bulk operations on each gfxfb_blt if shadow buffer enabled

[aokblast]

Summary

Previously, gfxfb_blt flushed the framebuffer on every call. Since a
single drawing operation may invoke gfxfb_blt multiple times, this can
result in unnecessary flushes.

Instead, write updates to the shadow buffer (when present) and mark the
affected area as dirty. Flushing is deferred so multiple gfxfb_blt calls
can be coalesced into a single update. As before, only the dirty region
is flushed.

This fixes the slow bootloader problem in some platforms.

[aokblast]

Flush and read from the framebuffer directly while doning framebuffer -> buffer

[adrian]

hi! Oh, so this is to flush a partial region of the shadow frame buffer rather than the whole framebuffer? How does this accelerate things given the current framebuffer API in stand/ doesn't have an explicit flush() ? (ie, i think every putchar() is an individual rectangle blit, no?)

stand/common/gfx_fb.c

937

Maybe refactor this into a separate routine (gfxfb_blt_shadow() ?) and call that if needed?

[adrian]

(ie, can you list some of the drawing done by the bootloader that's being accelerated by this?)

[aokblast]

In D57373#1314470, @adrian wrote:

(ie, can you list some of the drawing done by the bootloader that's being accelerated by this?)

This works not because of partially flushing. It is because we aggregate multiple flush into one single operation. For example, gfx_fb_drawrect flushes four times as we call gfxfb_blt four times. Now, gfxfb_blt does not flush the buffer and waiting for gfx_fb_flush call. It just writes to the shadow buffer. Then there is a explicit flush operation to flush the buffer.

[imp]

I like this. I haven't delved into the fine details though, but it looks like adrian is, so my acceptance is conditional on making him happy.

[adrian]

ok, i see where the multiple flushing is happening now. and yeah this makes drawing a single pixel have even more overhead! But that's not specifically your problem, its the API that's exposed.

stand/common/gfx_fb.c

943

Note - reads can be really really slow; if you're not using the shadow buffer then (a) the flush may occur extra overhead if someone's doing some read/modify/write operations, and (b) one of the reasons for having the shadow buffer /is/ to accelerate reads.

If we're concerned about reading the existing firmware screen and it being inconsistent then we should consider just doing a full screen blank first (which i thought we were doing), or reading the framebuffer into the shadow buffer.

[aokblast]

In D57373#1314470, @adrian wrote:

(ie, can you list some of the drawing done by the bootloader that's being accelerated by this?)

stand/common/gfx_fb.c

943

The only place uses read is in gfx_fb_cons_display. And it has gfx_state.tg_shadow_fb != NULL with early returns without calling read. We never read from framebuffer if shadow_fb is available.

Also, we still need to flush the shadow buffer before writing to shadow buffer as it might be dirty.

And if we are not using shadow buffer, tg_dirty will be false and thus it is just a if statement in gfx_fb_flush.

[adrian]

stand/common/gfx_fb.c

943

ok, if this stuff needs to get faster for some other weird usecase then we can do that. Thanks!