[libre-riscv-dev] Vulkanizing

[Luke Kenneth Casson Leighton]

On Wednesday, February 19, 2020, Jacob Lifshay <programmerjake at gmail.com>
wrote:

> On Tue, Feb 18, 2020, 23:58 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > On Wednesday, February 19, 2020, Jacob Lifshay <programmerjake at gmail.com
> >
> > wrote:
> >
> > > On Tue, Feb 18, 2020, 23:20 Luke Kenneth Casson Leighton <
> lkcl at lkcl.net>
> > > wrote:
> > >
> > > > On Wednesday, February 19, 2020, Jacob Lifshay <
> > programmerjake at gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > On Tue, Feb 18, 2020, 22:49 Luke Kenneth Casson Leighton <
> > > lkcl at lkcl.net>
> > > > > wrote:
> > > > >
> > > > > > On Wednesday, February 19, 2020, Jacob Lifshay <
> > > > programmerjake at gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > That is 8 flops/core/cycle of fp32, 16 for fp16, and, depending
> > > > > > > on how we implement it, either 2 or 4 flops/core/cycle of fp64.
> > > > > >
> > > > > > 2 because ... no 4 if you count FMAC as 2, and we can do 2 per
> > clock
> > > @
> > > > 64
> > > > > > bit.
> > > > > >
> > > > > > the odd ALU will do 2FMAC FLOPS @ 64 bit, the even likewise.
> > > > > >
> > > > >
> > > > > The idea was that we could have the 128-bit ALU do 2xfp64 or, since
> > > fp64
> > > > is
> > > > > much less important and takes lots of area, just 1xfp64.
> > > >
> > >
> > > it could work by having just one half support fp64, the other half
> could
> > > still run 2xf32 or other combinations.
> >
> >
> > that gets messy because the Function Units are designed to hold 32 bit
> data
> > ready for 32 bit operations.
> >
> > the way 64 bit works is to have 2 neighbouring 32 bit Function Units
> > "temporarily synchronise" to handle a 64 bit op.
> >
> > one FU holds 32 HI
> >
> > the other holds 32 LO.
> >
> > the partition gate is opened to make a 64 bit op, and job done.
> >
> > 32 HI result goes into HI regfile lane, 32 LO result goes into LO regfile
> > lane.
> >
> >
> >
> > to do 64 bit on a 32 bit partition will be a frickin nuisance.
> >
>
> Actually, what I had meant was to support only the following two 128-bit
> alu modes (ignoring 8 and 16-bit):
>
> | 32 | 32 | 32 | 32 |
> | 64 ---- | 32 | 32 |
>
> Not: | 64 | 32 | 32 | 32 |


it's only | 32 | 32 |  therefore
| 64 --- | is possible.

there are 2 of these one for odd one for even.

no way we are doing 128 bit ALUs.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68