[Libre-soc-bugs] [Bug 734] add Partitioned SimdSignal support for elwidth-based layouts (currently ElwidPartType)

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=734

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---

    elwid       |    |        |  |      |    |   
    0b00  x x x  x x  x x x x |B7 B6B5B4 B3B2 B1B0A2A1A0
    0b01  x x x |B7B6 B5B4AaA9 A8|x x x |B3B2 B1B0A2A1A0
    0b10  B7B6Ae AdAc|B5B4AaA9 A8|B3B2A6 A5A4|B1B0A2A1A0

this example, from the slice page, is showing up an oversight
in PartitionedCat (and other places that have a get_chunk
function)
https://libre-soc.org/3d_gpu/architecture/dynamic_simd/slice/

the issue is that PartitionedCat etc. were not designed with
disparate PartitionPoints in mind, and the case of a fixed-overall-width
and a fixed-element-width is breaking the assumptions.

a workaround _would_ be to convert all of the input parameters
(PartitionedCat.catlist) to the exact same partitionpoints
but i am currently unable to see how to do that.

determining the new lane_shapes is easy enough: just add up
the widths at each elwidth of every contributor in catlist,
create a new lane_shapes, job done.

the issue is: even with those new lane_shapes after creating
a new PartitionPoints, how the heck do you convert each one
of the catlist contributors to the same layout, when each
contributor is smaller and would fit in totally different
places? i don't believe i'm overthinking this.

it may need a design shift in PartitionedCat itself.

need to look at it some more.

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