[Libre-soc-dev] SV whitepaper

[Jacob Lifshay]

On Sat, May 7, 2022, 12:58 lkcl <luke.leighton at gmail.com> wrote:

> https://libre-soc.org/openpower/sv/SimpleV_rationale/?updated
>
> i figured it was time to do not just a comparative analysis and rationale
> of SimpleV but also to document the next advancements, where things can go
> next.
>
> for example by adding ZOLC as a first priority for 3D, Texture image XY
> scaling can be done as a Memory-driven (Snitch-like) deterministic schedule
> either through one massive instruction (Horizontal-First) or several
> smaller ones
>
> OR... and this is cool...
>
> by having Extra-V-like coordinated pushing of the Texture Instructions
> *down to the memory* there would be no need for a L1 Texture Cache *at
> all*.


that's not actually true, many 3d algorithms read/write to a section of an
image (too big for cpu regs, but fits in a cache and/or tile buffer) many
times before finally sending the results to ram. caches are still needed
for the algorithms that computation in ram without caches are poorly suited
to.

an example of an algorithm better suited to having a cache is gaussian blur
(or other large 2d image convolutions) -- each texel is read
hundreds/thousands of times per output pixel...having reads run at the
150Mhz rate of ram cells rather than the >>500Mhz rate of a cache makes it
run much slower when there isn't a cache even if you have zillions of cores
in ram.

ZOLC Deterministic Schedules would send coordinated OpenCAPI requests down
> to the actual Memory ICs, and give them a fragment of code to execute that
> would *also* include OpenCAPI requests for data that the *Memory* IC needed.
>
> thoughts appreciated because this is an absolutely mental concept that
> starts to go waaay down the rabbithole.
>

it's a really neat idea, just don't create a design that is only good at
in-memory computation with main cpus that are too slow since you focused
all your effort on the in-memory cpus...

Jacob