[Libre-soc-bugs] [Bug 713] PartitionedSignal enhancement to add partition-context-aware lengths
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Tue Oct 12 12:45:33 BST 2021
https://bugs.libre-soc.org/show_bug.cgi?id=713
--- Comment #72 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #68)
> looking through the code, you got what part_counts is mixed up:
> https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part/
> layout_experiment.py;h=1f0b761a019fae0fd0005a52649c5f5ad080bea2;
> hb=48f1e8c97dd4adc9d9161e362f389fbf70506033#l94
> You wrote:
> > 94 # for each element-width (elwidth 0-3) the number of partitions is given
> > 95 # elwidth=0b00 QTY 1 partitions: | ? |
> > 96 # elwidth=0b01 QTY 1 partitions: | ? |
> > 97 # elwidth=0b10 QTY 2 partitions: | ? | ? |
> > 98 # elwidth=0b11 QTY 4 partitions: | ? | ? | ? | ? |
> > 99 # actual widths of Signals *within* those partitions is given separately
> > 100 part_counts = {
> > 101 0: 1,
> > 102 1: 1,
> > 103 2: 2,
> > 104 3: 4,
> > 105 }
>
>
> part_counts is actually a dict from elwid values to the number of parts *in
> a single lane*, *not* the number of parts in the whole SIMD signal.
tcktcktck... *thinks*... where's the misunderstanding... we need some
terminology.
SIMD Lanes seems to refer to the "whole blob" (the entire batch of
elements, irrespective of subdivision).
http://15418.courses.cs.cmu.edu/spring2015/lecture/gpuarch/slide_003
"part_counts is actually a dict from elwid values to the number
of parts *in a single lane*"
yep, i'd agree with that.
"*not* the number of parts in the whole SIMD signal"
which would be *after* the subdivisions have taken place, and could
potentially include blank (padding) sections. i.e. PartitionPoints.
would you agree then that one was "requested" and the other "allocated"?
(sort-of. PartitionPoints is admittedly a different data structure,
but layout with the elwidth==i stuff makes it *possible* to express
part_points-including-padding)
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs
mailing list