Michael Kelly, le sam. 14 nov. 2026 19:34:26 +0000, a ecrit: > On 11/11/2026 00:10, Samuel Thibault wrote: > > Michael Kelly, le mar. 10 nov. 2026 21:32:55 +0000, a ecrit: > > > Your being so surprised makes me wonder if there is something else > > > happening. > > Possibly the video memory is really not made for reading and thus very > > slow. > > I ran a really basic user-land test case using an 800x600 (32bpp) frame > buffer mapped with INTEL_PTE_NCACHE|INTEL_PTE_WTHRU.
If you disable cache, I'm not surprised that reading gets slow, because you end up waiting for the latency of the memory for each read, rather than reading a whole cache line. > The writes would undoubtedly be faster, maybe much more so, with write > combining which I intend to prototype. Yes, write combining will allow to write a whole cacheline. > How would you feel about introducing a time buffer between kdcnputc() and it > being displayed? I'm thinking that I could buffer the 'print' and have a > background thread triggering perhaps after 0.1 or 0.2 seconds to output the > altered buffer. At times of high output that would reduce the scrolling > considerably. If the volume of scroll operations reduces hugely then their > performance won't be so critical and a simple 'memmove' might suffice. That would be a bit tricky because you'll have to remember how print and scroll interact etc. While, again, what would you want to actually memmove? The application output? It does not really make sense to scroll it since it's the gnumach output that needs to scroll, on top of the application output. As mentioned in a previous mail, it looks completely ok to me to implement scrolling by just drawing the known text of the gnumach console at the new position, and leave the rest alone. That'll be way faster than memmoving everything. Samuel
