[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
Thu Oct 28 12:41:27 BST 2021


--- Comment #121 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
context: this is starting to get complicated so i am moving the discussion
back to the bugtracker


i just put in some unused code (in advance of setting up the examples
in the URL https://libre-soc.org/3d_gpu/architecture/dynamic_simd/shape/


it's over 50% comments because it's... complicated (dual mathematics rules,

basically: when both LHS and RHS are PRIORITY_FIXED (both had a lane_shapes
of None), then it should be obvious that the "Correct Thing To Do" is just
to multiply the two fixed_widths together and create a SimdShape out of


because *both* LHS and RHS were established (created) with the requirement
that "elwidths shall be auto-computed to fill the entirety of the partition,
as determined by overall width and the vec_el_counts,
regardless of what elwid is set to.

on the other hand, when *either* LHS or RHS have had an elwidths argument
given, it is the elwidths that have to be preserved (multiplied)

    result.lane_shapes[0] = LHS.lane_shapes[0] * RHS.lane_shapes[0]
    result.lane_shapes[1] = LHS.lane_shapes[1] * RHS.lane_shapes[1]

the only case i'm not sure about is PRIORITY-BOTH, there.  i don't
believe it's safe for the return result to be PRIORITY-BOTH, because
you could have LHS[0] = 1000, RHS[0] = 1, and LHS[1] = 1, RHS[1] = 999,
and a fixed_width doesn't work out, there.

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

More information about the libre-soc-bugs mailing list