Samuel,
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. This is a total of
1875kb per screen read/write. The test copies the frame buffer into a
malloc buffer and/or writes the same back to the video RAM. As a
comparison, the same test is also run but copying to and from a 2nd
malloc buffer. The following table shows the memory combinations and the
number of completed memcpy calls per second.
Read from RAM 5311
Write to RAM 5311
Read from VRAM 88 (60 times slower)
Write to VRAM 156 (34 times slower)
The writes would undoubtedly be faster, maybe much more so, with write
combining which I intend to prototype.
The total memory moved per scroll with the EGA driver is tiny in
comparison to the frame buffer. The EGA scroll overhead possibly has
little impact on the boot time but without some major improvement this
is not the case with the frame buffer. I've seen boot time varying from
41s to 156s for different implementations so far so these poor
implementations are adding major overhead.
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. There would need to be something like a cnsync
for critical output like Panic.
Cheers,
Mike.
