Hi Simon, On Sat, May 23, 2020 at 12:34 AM Simon Glass <s...@chromium.org> wrote: > > Hi Bin, > > On Fri, 22 May 2020 at 09:30, Bin Meng <bmeng...@gmail.com> wrote: > > > > Hi Simon, > > > > On Wed, May 20, 2020 at 7:11 AM Simon Glass <s...@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