[Libre-soc-bugs] [Bug 546] data moving / merging Function Unit (FSM)

[bugzilla-daemon at libre-soc.org]

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

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
moved from bug #230

(In reply to Jacob Lifshay from bug 230 comment #52)

> So, I think variable shifts will be needed for other stuff, but we should
> just use the dedicated texture read instructions here.

arg ok, so just to be clear about this: large amount of lane-crossing is not
ok.

we are not going to be putting in QTY N massive 64 bit 16-to-16 multi ported
crossbars for example.

however if we do *not* do so then the power consumption of moving data in and
out of registers will also hit us.

large shift registers and cyclic buffers on the other hand are a compromise
that trades latency yet still provides throughput.

particularly given that 444 exists in VK and i assume that is packed we need to
be able to unpack large sequences of those in a sane fashion.

that basically means that large shift register, with the data "passing by" the
appropriate 64 bit "Lane", extracting the R or the G or the B at the
appropriate time-slot.

yes, not involving crossbar routing to get at the data.

the input operands are organised as:

* Lane0 src dest
* Lane1 src dest
* Lane2 src dest
* Lane3 src dest

and consequently if the 4-4-4 data comes in on Lane0 and needs to be converted
to FP64 it will be another 2 clock cycles to shift to where Lane2 can read the
B value.

this is going to be sufficiently complex that we do not want to be duplicating
it or underestimating it.

so to emphasise here: LD-textures needs to be fundamentally aware that it
cannot naively lane-cross its data.

we will almost certainly have to use micro-coding, perform some straight
aligned 64 bit LDs then back-end that into the Large ShiftReg FSM to perform
the actual extraction.

if that's not sequential data it's going to be hell, sigh.

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