Announcement

Collapse
No announcement yet.

Libre RISC-V GPU Aiming For 2.5 Watt Power Draw Continues Being Plotted

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

  • #41
    Also, on the subject of cache coherency, consider how much floating-point performance IBM's Cell managed. In just an 8+1-core chip, they managed over 100 GFLOPS, more than a decade ago. The 8 PPE cores had only 128-bit vector engines, like your design, but were in-order with 2-way SMT.

    https://en.wikipedia.org/wiki/Cell_(microprocessor)

    The secret? The Cell used scratch-pad memory - not cache. This made it notoriously difficult to program, but then they weren't using OpenCL, which would've significantly eased the burden on programmers of managing data movement, among other things.

    Comment


    • #42
      Originally posted by ldesnogu View Post
      Jeremy Bennett found that ARM Thumb is denser than RISC-V compressed: https://fosdem.org/2019/schedule/event/riscvcompact/
      oo that's an extremely valuable and insightful analysis. it would be particularly interesting to see it repeated for RV64C, as there's something odd about the arm64 that increases code size and requires 50% larger L1 I-cache to compensate.

      Also I guess you know a cache is not a CAM. You only need as many comparators as the number of ways of your cache and even then you can use way predictors. Anyway even if you completely removed the I-cache you'd not gain 40% of power.
      appreciated. well, we can't remove the I-cache, that's for sure.

      Comment


      • #43
        Originally posted by coder View Post
        The secret? The Cell used scratch-pad memory - not cache. This made it notoriously difficult to program, but then they weren't using OpenCL, which would've significantly eased the burden on programmers of managing data movement, among other things.
        times move on, eh? yyeah we will need to add a scratch memory area as well: its primary purpose will be as a direct target for batches of 4xFP32 (A,R,G,B) to be converted in a single cycle to a batch of 32-bit 8/8/8/8 ARGB pixels. (edit: see https://www.phoronix.com/forums/foru...37#post1081537 for additional uses)

        that's just one of the things that we've established will be needed in order to achieve the goal. AndyChow: we don't have all the answers, we don't know everything: there are still areas where we don't know what we don't know. and y'know what? that's okay. we'll find out (sooner rather than later being better), and when we do, we'll iteratively improve until the goal - the target - *is* reached. it may take 1 year, it make take 2, it may take 3: we'll keep at it.
        Last edited by lkcl; 02-20-2019, 09:35 PM.

        Comment


        • #44
          Originally posted by lkcl View Post
          oo that's an extremely valuable and insightful analysis. it would be particularly interesting to see it repeated for RV64C, as there's something odd about the arm64 that increases code size and requires 50% larger L1 I-cache to compensate.
          For AArch64, I agree that 64-bit RISC-V compressed would be smaller. But what do you think is odd about it?

          Anyway I'm still unconvinced that reducing Icache size by 25% will lead to 40% less power; in fact I'm rather confident it's wrong. But that doesn't mean you can't achieve that goal of 40% less power overall, I will just wait for proof :-)

          Comment


          • #45
            Originally posted by ldesnogu View Post
            For AArch64, I agree that 64-bit RISC-V compressed would be smaller. But what do you think is odd about it?

            Anyway I'm still unconvinced that reducing Icache size by 25% will lead to 40% less power; in fact I'm rather confident it's wrong. But that doesn't mean you can't achieve that goal of 40% less power overall, I will just wait for proof :-)
            me too

            Jeff Bush's Nyuzi paper was particularly informative in this regard, as power-performance in GPUs is critically related to a lot of factors, one of the heaviest being getting data through the L1 / L2 caches.

            http://www.cs.binghamton.edu/~millerti/nyuziraster.pdf

            it's pretty essential to have enough registers such that the data is kept in the register file (after LD) until it is absolutely necessary to push it back out (STORE), and even then, if that can be avoided it would be better. this is why most GPUs have a minimum of 128 floating-point registers.

            as GPUs are pretty much proprietary, it's not exactly like we can examine an existing design's source code. we can study work such as MIAOW (which is a parallel compute engine, not a GPU), and Nyuzi, and the available documentation on Broadcom Videocore IV... but ultimately, we just have to get on with it, generate some verilog, synthesise it and see what happens.

            Comment


            • #46
              Originally posted by lkcl View Post
              it's not exactly like we can examine an existing design's source code. we can study work such as MIAOW (which is a parallel compute engine, not a GPU),
              Did you happen to see my post:

              https://www.phoronix.com/forums/foru...16#post1081216

              It got delayed by the spam filter, due to the number of links I included. Anyway, perhaps some worthwhile references.

              Another, more recent example of a highly efficient (i.e. GFLOPS/W) architecture that reminded me of Cell is:

              https://en.wikipedia.org/wiki/Sunway_SW26010

              Its main compute cores have I-cache, but scratch pad RAM for data.

              Comment


              • #47
                Originally posted by lkcl View Post
                times move on, eh? yyeah we will need to add a scratch memory area as well: its primary purpose will be as a direct target for batches of 4xFP32 (A,R,G,B) to be converted in a single cycle to a batch of 32-bit 8/8/8/8 ARGB pixels.
                I am planning on using the scratchpad for the portion of the framebuffer and z-buffer that is currently being worked on. so, it's much more than just a target for rgba 8888 pixels.

                Comment


                • #48
                  Originally posted by programmerjake View Post
                  I am planning on using the scratchpad for the portion of the framebuffer and z-buffer that is currently being worked on. so, it's much more than just a target for rgba 8888 pixels.
                  In neural network inferencing, it's tremendously useful to have some fast, on-chip memory.

                  For the sake of security, I would make it private to each core. That way, you needn't take the hit of accessing it through a MMU.

                  Comment

                  Working...
                  X