| Message ID | 20200519231058.19945-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | x86: video: Speed up the framebuffer | expand |
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? > 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. Regards, Bin
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. > > > 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, Simon
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
Hi Bin, On Fri, 22 May 2020 at 17:09, Bin Meng <bmeng.cn at gmail.com> wrote: > > 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? It is supported by U-Boot on ARM. If you enable write-back caching, you see nothing on the display. I did try that, but no dice. Regards, Simon [..]