Liste des Groupes | Revenir à c arch |
On Thu, 1 Aug 2024 20:34:28 +0000, Scott Lurndal wrote:
mitchalsup@aol.com (MitchAlsup1) writes: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.
Thanks for the explanation.
In my case LLC is simply the front end for DRAM so a device
write will spew data into LLC where it will wait to be written.
Meanwhile, cores (or other devices) can access it directly
from LLC as if it were from DRAM except at lower latency.
>
Les messages affichés proviennent d'usenet.