[PATCH 00/26] x86: video: Speed up the framebuffer

[Bin Meng]

Hi Simon,

On Sat, May 23, 2020 at 12:34 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Bin,
>
> On Fri, 22 May 2020 at 09:30, Bin Meng <bmeng.cn at gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Wed, May 20, 2020 at 7:11 AM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Some architectures use a cached framebuffer and flush the cache as needed
> > > so that changes are visible. This is supported by U-Boot.
> > >
> > > However x86 uses an uncached framebuffer with a 'write-combining' feature
> > > to speed up writes. Reads are permitted but they are extremely expensive.
> > >
> >
> > Is it possible to use cached framebuffer on x86?
>
> It might be possible on newer chips. I see so much conflicting stuff
> about flushing the cache, though. The write-through cache is slow for
> reads. The write-back cache never writes unless you flush.

But you said "This is supported by U-Boot." So if we use cached frame
buffers on x86, the video driver already handles the cache coherency
for us? Not sure what conflicting stuff did you see?

>
> >
> > > Unfortunately, reading from the frame buffer is quite common, e.g. to
> > > scroll it. This makes scrolling very slow.
> > >
> > > This series adds a new feature which supports copying modified parts of
> > > the frame buffer to the uncached hardware buffer. This speeds up scrolling
> > > dramatically on x86 so the extra complexity cost seems worth it.
> > >
> > > In an extreme case, the time to print the environment on minnowboard with
> > > 1280x1024 and CONFIG_CONSOLE_SCROLL_LINES disabled is reduced
> > > significantly, from 13 seconds to 300ms.
> > >
> >
> > Thanks for the series. The improvements sounds great! I will get one
> > minnowmax board to test this series soon.
>
> Yes it should work on that.
>

Regards,
Bin