[libre-riscv-dev] [Bug 216] LOAD STORE buffer needed

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Tue Mar 24 20:19:12 GMT 2020


http://bugs.libre-riscv.org/show_bug.cgi?id=216

--- Comment #18 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #17)
> If we're having multiple L1 caches, we should implement them to appear as if
> there is a single L1 cache -- no extra instructions are needed to flush one
> cache before accessing the other,


yes, agreed.  it appears, from the advice on comp.arch, that it is normal to
"stripe" the L1 cache, using e.g. bit 4 of the address (when using 128 bit
cache lines) to select odd or even halves.

if there are two separate LD/ST buffers, one for each half, this doubles the
bestcase data throughput at a cost of 40% misses in the general case (due to
each half being, duh, half the size).

however yes when it comes to flushing the cache these halves can, must and will
appear to be coherent as if they were a single L1 cache.


> For GPU workloads, they still have some accesses (the majority for a tiled
> architecture -- what Kazan is) that benefit from a L1 cache. basically, it
> splits the screen into small squares/rectangles (bins) and accumulates a
> list of rendering operations (binning) then for each square/rectangle (bin)
> it renders all the operations inside it in sequence, so the pixels are
> repeatedly stored and loaded until that bin is done rendering.
> 
> Texture access also benefits from a cache since nearby pixels are accessed
> together and often the accesses are overlapping.

ok.

ok so those 1 MB texture buffers you mentioned before are accessed multiple
times in near-succession?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-riscv-dev mailing list