Re: [RFC] Hacky MTRR support

[Seth Goldberg]

Quoting Colin D Bennett, who wrote the following on Mon, 28 Jun 2010:

> On Fri, 25 Jun 2010 09:58:34 +0100
> Colin Watson <address@hidden> wrote:
>
> > I recently posted ("Subject: [PATCH] Optimise memset on i386" -
> > sorry, I don't seem to have a route to lists.gnu.org at the moment so
> > I can't post an archive link) about optimising GRUB's video
> > initialisation, and hinted that it might be possible to do better by
> > implementing MTRRs as well in order to allow the system to combine
> > writes to video memory rather than taking a cache stall for every
> > single write.  I can report that, at least on the hardware I was
> > using, it does make a significant difference: filling the screen with
> > solid colour now takes 10 milliseconds rather than 160!  This ended
> > up shaving about a second off the boot time of the project I'm
> > working on.
>
> In addition to the improved startup speed, I see the potential for a
> huge increase in graphical menu responsiveness if caching is enabled.
> Would framebuffer draw and image blitting performance be improved by
> using write-combining with MTRRs?

  Yes, I think it would.  I was thinking about this over the weekend and I 
think if we examine the PCI BARs and ensure that the memory we're adding to 
the variable-length MTRRs is marked prefetchable, that should exclude those 
cards that have registers mapped in that area (besides, I seriously doubt 
there would be registers in the framebuffer section of memory -- that would 
just be counterproductive for any graphics adapter), and should be the safety 
check vladimir's asking for as well.

 --S