Liste des Groupes | Revenir à c arch |
mitchalsup@aol.com (MitchAlsup1) writes:Thanks for the explanation.On Thu, 1 Aug 2024 17:39:24 +0000, Scott Lurndal wrote:>
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:>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.
In addition, ARM64 CPUs include allocation hints in
the memory type such as 'read allocate', 'transient read allocate',
'write allocate' as well has having optionally multiple coherency
domains (inner and outer sharable).
Sorry, I don't understand the word 'allocate' ?!?
"allocate a cache line".
>
Example would be a DMA request with the 'read allocate' hint
is allowed to be allocated in LLC instead of being stored in
DRAM.
>
Used when software expects the DMA data to be immediately.
"no allocate" for CPU initiated stores/loads would be equivalentWhen using VVM, vector LDs and STs are considered non-temporal
to write-through-but-do-not-allocate-a-line-for-it (e.g
non-temporal stores/loads). There are instructions for
individual N/T accesses, but with the region attributes it
can be applied to normal loads/stores for a whole page
or set of pages.
Les messages affichés proviennent d'usenet.