[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