Announcement

Collapse
No announcement yet.

Libre RISC-V Accelerator Secures 300k EUR In Grants, Still Undecided About The ISA

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • lkcl
    replied
    some nice news btw, will leave the phoronix team to decide if they want to pick it up soon, the OpenPower Foundation released their EULA which was what we were waiting on. it looks really good, very well designed.

    Leave a comment:


  • lkcl
    replied
    Originally posted by Michael View Post

    Their current plan is focused on Kazan for Vulkan, but LLVMpipe theoretiically would work too.

    Keep in mind they are setting very low performance expectations (~25 FPS at 720p) compared to Intel and other efforts aiming for legitimately high performance.
    keep in mind that there has been a ramp-up curve here spanning nearly 40 years. also that you are referring to companies that do full custom ASICS, which cost USD 100 million to design.

    yes, without realising it, you are saying, "why are these people not doing a full custom ASIC as their very first chip, why have they not gone for VC funding of over half a billion dollars so they can do a few iterations of full custom ASICs?"

    um....

    walk before run.

    therefore we will be doing a 180nm chip first. this is a sponsored tapeout that will only cost USD 600 per square millimetre. we need around 40 square millimetres.

    where normally a chip would be half a million, one million, two million just for the mask charges, we do not have those, just the production costs in a 180nm shuttle service.

    once we have iterated at that level, we can move up to the next level (45nm quad core).

    once we have iterated at that level, we can move up again with VC funding to 1000 cores and 7nm and so on.

    this is just a responsible way to do things.

    Leave a comment:


  • lkcl
    replied
    Originally posted by pkese View Post

    There already exist a bunch of opensource RISC-V implementations: https://github.com/riscv/riscv-cores-list
    How about taking one of those and add the Vector extension to it?
    someone else mentioned larrabee in this thread: that and jeff bush's work on nyuzi tells you what you need to know.



    I'm trying to understand how is this different (i.e. what's the innovative contribution, besides the 'not invented here' syndrome)...
    appreciated, it's a good question. i spent 18 months prior to putting in the NLNet *first* Grant request, because i despise NIH. i have RSI: typing gets painful, therefore why would i deliberately do that, yeah??

    a fantastic high performance Vector Processor simply does not make a GPU. this is just a fact. you can have all the Vector Processing in the world, however the last bit of accuracy in FP32 (ULP) requires 4x the amount of hardware (4x the power consumption) compared to a less accurate *useable* GPU equivalent, where exact IEEE754 compliance is simply not necessary all the time.

    thus you can have a perfect Vector Engine yet compared to a GPU centric engine its power performance is completely noncompetitive.

    in addition, certain types of 3D computation simply do not fit well into "standard" Vector operations. Jeff Bush illustrates several in his Nyuzi paper.

    basically, 3D GPU is a whole new level above a plain Vector Engine, hence we have *not* gone mad and deluded ourselves that we are reinventing second hand wheels.

    it would be great to use pulpino however unfortunately they tied their work too closely to the RISCV Vector Extension to be able to do so.


    Leave a comment:


  • log0
    replied
    Originally posted by OneTimeShot View Post
    ...
    Or you'll have to restart with blank sheet of paper and a new instruction architecture ground up designed specifically for highly parallel, pipelined numerical calculation...
    Nobody starts with a blank sheet nowadays. You have libraries of function blocks, like rasterizers, texture samplers etc.

    So those graphics instruction blocks should be perfectly reusable if someone wanted to design a more performance oriented chip. That is the real value of this project imho.

    Leave a comment:


  • OneTimeShot
    replied
    Originally posted by programmerjake View Post

    That's true, but only if you ignore the graphics instructions we're adding. Once added, the ISA would include all the important operations from known-working GPU ISAs such as AMD GCN, so it would then be completely suitable to implement a GPU. The rest of what's needed are good drivers and good microarchitecture.

    Additional source code link: https://salsa.debian.org/Kazan-team
    Ok - but to avoid a complex technical discussion, I'll just point out that modern GPUs have >4000 computation cores. So you'll be trying to build a multi-core CPU that is significantly larger than anything on the market today to get anywhere near - and *really* not be using it particularly efficiently. Or you'll have to restart with blank sheet of paper and a new instruction architecture ground up designed specifically for highly parallel, pipelined numerical calculation...

    Leave a comment:


  • programmerjake
    replied
    Originally posted by OneTimeShot View Post

    That's true. Neither RISC-V nor Power architecture is sensible for a GPU implementation.
    That's true, but only if you ignore the graphics instructions we're adding. Once added, the ISA would include all the important operations from known-working GPU ISAs such as AMD GCN, so it would then be completely suitable to implement a GPU. The rest of what's needed are good drivers and good microarchitecture.

    Additional source code link: https://salsa.debian.org/Kazan-team

    Leave a comment:


  • OneTimeShot
    replied
    Originally posted by programmerjake View Post
    A lot of the hardware and software work doesn't actually depend on which ISA we pick.
    That's true. Neither RISC-V nor Power architecture is sensible for a GPU implementation.

    For everyone else, I believe that the code is here:
    https://git.libre-riscv.org/

    the issue tracker is here:
    http://bugs.libre-riscv.org/

    and the mailing list is here:
    http://lists.libre-riscv.org/pipermail/libre-riscv-dev/

    People can read these (it won't take long) and make up their own minds...

    Leave a comment:


  • programmerjake
    replied
    Originally posted by starshipeleven View Post
    I guess the money for the EOMA68 has finished and he needs to eat (yes it's the same guy). Not that the EOMA68 has shipped or anything.
    Just to clarify, in case anyone was wondering, LKCL is part of EOMA68, however, I am not.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by OneTimeShot View Post
    Wow - from what I've seen of the Libre RISC-V GPU project (which isn't much - they haven't even picked POWER or RISC-V) this is going to be money down the drain.
    I guess the money for the EOMA68 has finished and he needs to eat (yes it's the same guy). Not that the EOMA68 has shipped or anything.

    Leave a comment:


  • programmerjake
    replied
    Originally posted by OneTimeShot View Post
    Wow - from what I've seen of the Libre RISC-V GPU project (which isn't much - they haven't even picked POWER or RISC-V) this is going to be money down the drain.
    A lot of the hardware and software work doesn't actually depend on which ISA we pick. For example, I'm currently working on Kazan (the Vulkan driver), writing the shader compiler code that translates from SPIR-V to LLVM IR (as well as potentially other backend compilers, such as GCC or Cranelift) and performs the required vectorization steps to translate from SIMT to variable-length vectors.
    Last edited by programmerjake; 29 December 2019, 05:59 PM. Reason: most -> a lot

    Leave a comment:

Working...
X