OSDev.org

If you're not going to use MTRRs or PAT, set your pages to WB. The effective memory type will be whatever the firmware decided to program into the MTRRs.

I wouldn't rely on BIOS programming MTRRs properly for video memory. I had a bug in this that resulted in poor performance on Intel

If you're not going to use MTRRs or PAT, you have to live with whatever poor decisions the firmware has made.

I think PAT is the way to go. I avoid using MTRRs. My problem was that only BSP had the correct PAT settings, and when video was drawn from an application core, things was really slow.

Thanks for the information. I will add PAT support to my kloader and later kernel

And another question comes to my mind.

In Write-Combined mode, all accesses might be reordered. If I want to implement scrolling by reading the framebuffer line per line and copy the contents to the line before, wouldn't that reordering mess up things?

Memory order only concerns independent accesses. If you store into location a the value from location b and then into b the value from c, the CPU sees the load-store dependency and will not reorder the accesses the wrong way around. It might still move the accesses elsewhere, and with write-combining it might just do them a little bit later, but it will not do them the wrong way around.

sebihepp wrote: ↑Wed Sep 11, 2024 7:30 am And another question comes to my mind.

In Write-Combined mode, all accesses might be reordered. If I want to implement scrolling by reading the framebuffer line per line and copy the contents to the line before, wouldn't that reordering mess up things?

You should never read the frame buffer. You should keep a copy of it in ordinary memory and then copy the contents to the framebuffer when appropriate.

This is because of how PCI operates. Reading PCI memory is quite slow because it results in multicycle operations in the PCI device, and PCI devices will seldom be optimized to handle reads. Writes can be buffered easily and thus are typically single cycle pipelined operations. That's why modern PCI devices use memory schedules. It's much faster for a PCI device to send large amounts of data to physical memory (PCI devices can issue 128 byte write requests, which CPUs cannot), than to let the CPU read out data from the PCI device.

rdos wrote: ↑Wed Sep 11, 2024 7:56 am You should never read the frame buffer. You should keep a copy of it in ordinary memory and then copy the contents to the framebuffer when appropriate.

This is because of how PCI operates. Reading PCI memory is quite slow because (...)

Thanks, that is some important info I missed somehow. I will implement DoubleBuffering ASAP.