[libre-riscv-dev] sv 1d/2d/3d data shaping
Jacob Lifshay
programmerjake at gmail.com
Mon Oct 15 22:17:25 BST 2018
That should work. For a 4x4 matrix (the biggest required) it could be set
up to have a 4x4xN layout, where N is the number of shaders running at once.
Jacob
On Mon, Oct 15, 2018, 12:53 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:
> On Mon, Oct 15, 2018 at 7:53 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> >
> > ok so i thought about this a bit more, and i believe it may be
> > achievable with an additional (small!) CAM CSR table that contains the
> > dimensions required and the order in which they are to be applied. i
> > am reluctant to specify all the permutations required of 3D at this
> > stage however it may be ok to leave room for further expansion.
> >
> > the key thing here is to be able to "reorder" linear data with an
> > algorithm that, for 2D, would go something like this:
> >
> > xdim = CSRtb[reg].x_sz
> > ydim = CSRtb[reg].y_sz
> >
> > for idx in range(VL):
> > if (swap_xy)
> > {
> > new_idx = (idx % xdim) * ydim + (idx / ydim)
> > }
>
> >>> for idx in range(12):
> ... print (idx % 3) * 4 + (idx / 3)
> ...
> 0
> 4
> 8
> 1
> 5
> 9
> 2
> 6
> 10
> 3
> 7
> 11
>
> it needs to be divide by xdim in each case (not idx / ydim).
>
> that would make it possible to remap matrices of 3x4 into 4x3, but
> leaving the data *in-place*.
>
> my only concern is the addition of hardware logic which does the
> divide and multiply, however i think an alternative algorithm based on
> incrementing a pair of counters (for x in range(xdim): for y in
> range(ydim)) at the same time as the element idx is incrementing might
> do the trick.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>
More information about the libre-riscv-dev
mailing list