Sujet : Re: Arguments for a sane ISA 6-years later
De : already5chosen (at) *nospam* yahoo.com (Michael S)
Groupes : comp.archDate : 01. Aug 2024, 21:08:25
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20240801230825.00003cd2@yahoo.com>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
On Thu, 01 Aug 2024 17:10:28 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
BGB <cr88192@gmail.com> writes:
Some amount of the cases where consistency issues have come up in my
case have do do with RAM-backed hardware devices, like the
rasterizer module. It has its own internal caches that need to be
flushed, and not flushing caches (between this module and CPU) when
trying to "transfer" control over things like the framebuffer or
Z-buffer, can result in obvious graphical issues (and,
texture-corruption doesn't necessarily look good either).
The approach taken on AMD64 CPUs is to have different memory types
(and associated memory type range registers). Plain DRAM is
write-back cached, but there is also write-through and uncacheable
memory. For a frame buffer that is read by some hardware that can
access the memory independently, write-through seems to be the way to
go.
- anton
In theory WT regions can be used for frame buffers, but I would think
that in real world overwhelming majority of [few remaining Direct IO]
frame buffer applications use write-combining (WC) regions.
To remind to those of us who recently didn't re-read the relevant
topics of the manual, architecturally WC regions are weakly ordered and
uncached.
On the other hand, WT regions adhere to the same x86-TSO memory
ordering model as WB regions.
I don't believe that designers of iAMD64 CPUs pay much attention to
performance of WT regions, because of the absence of killer app.