Hi folks. While looking into ways to speed up the ARM HDLCD device, I started looking at how PixelPump was implemented. There is a LOT of events being scheduled, incremental work, etc.
It seems to me that while this might all be really flexible and accurate, it probably also has really significant performance overhead. For instance, do we need to keep track of what line of the screen we're on, scheduling and rescheduling events for it, calling a virtual function to notify a subclass, if nobody is actually paying attention? Do we need to convert pixels in small batches of 32? Or could we gather up a whole line (or a whole frame) and convert everything at once? Maybe defer until somebody actually needs to look at the framebuffer and then convert everything outstanding? I think if this was done carefully, the potential speed up would be significant and the loss of fidelity would be minor or none at all. I'm mostly looking at this code for the first time though, so there may be a lot of context I'm missing or things I'm not thinking of. Could someone please let me know if there's more to it than that? Gabe
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
