Hi Eric,
On Wed, Oct 17, 2012 at 6:07 PM, Eric Nelson eric.nelson@boundarydevices.com wrote:
Hi Simon,
On 10/17/2012 05:50 PM, Simon Glass wrote:
Hi Eric,
On Wed, Oct 17, 2012 at 5:41 PM, Eric Nelson eric.nelson@boundarydevices.com wrote:
Hi Simon,
On 10/17/2012 03:07 PM, Simon Glass wrote:
Hi Eric,
On Wed, Oct 17, 2012 at 8:34 AM, Eric Nelson eric.nelson@boundarydevices.com wrote:
On 10/17/2012 03:38 AM, Lukasz Majewski wrote:
<snip>
> Certainly we could make the flushing more fine grained. My reasons > for > not (so far) are: > > 1. It is simpler to flush everything (no need to figure out what part > of display has changed) > 2. The performance difference is likely to be small since flushing an > already-flushed range should be fast.
From the sake of "SW engineering" I would opt for fine grainedflushing. But if it turns out, that it costs too much, we can flush everything.
Is anybody else in a position to get some numbers about how/if performance is better when flushing at the more granular level?
Before deciding it wasn't worth the code, I implemented granular flushing and didn't see any noticeable degradation when just flushing at the end of all public functions as in this patch.
http://lists.denx.de/pipermail/u-boot/2012-September/134979.html
It seems that performance is the only reason for fine-grained cache flush operations
Also we might be talking about different things. I have taken the approach of flushing the whole display, but only after some display functions. We could flush only what has changed, which is what I was referring to as 'fine-grained'. You may have meant the idea of flushing after every function that touches the display, or a 'fine-grained' approach of only flushing after some functions.
You're right. That's what I get for chiming in quickly before attending a customer meeting: I jump to conclusions.
I thought 'finer-grained' referred to the way Anatolij originally did things:
http://git.denx.de/?p=u-boot.git;a=commit;h=bfd4be803bbb7d122c2e3aaf6eaf987e...
I tried to follow that lead, but it degenerated into a horrible mess of alignment checking.
My testing shows that flushing is pretty fast, but I was reluctant to flush after every putc() as it seemed egregiously inefficient.
I need to spend some time with the patch to figure out how you get around cache issues for keystroke echo.
Well my less-than-lovely approach was to use puts() for all character echo. That has a flush.
I just read through that and it makes perfect sense.
I'm anxious to test this and your CONFIG_CONSOLE_SCROLL_LINES patch to see how it operates at 1080P.
Without the CONFIG_CONSOLE_SCROLL_LINES patch, scrolling was incredibly slow.
Yes, it makes a big difference. Another option would be to enable the L2 cache.
Regards, Simon
Regards,
Eric