Announcement

Collapse
No announcement yet.

An LLVM Backend For the Raspberry Pi VPU

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

  • An LLVM Backend For the Raspberry Pi VPU

    Phoronix: An LLVM Backend For the Raspberry Pi VPU

    For those looking to make better use of the Raspberry Pi's VPU, an LLVM compiler back-end has been published for it...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    is this for OpenCL?

    Comment


    • #3
      Originally posted by Mangix View Post
      is this for OpenCL?
      OpenCL is an API to talk with the GPU, this thing allows you to write programs that will run on the raspi GPU directly.

      It is a module for a compiler called LLVM https://en.wikipedia.org/wiki/LLVM that allows it to write code meant to be run on the Raspi GPU.

      The most obvious use of LLVM in this case is for graphics drivers (LLVM compiles shaders for most GPUs around), but also for other specialistic applications that might want to run on the GPU.

      Comment


      • #4
        Originally posted by starshipeleven View Post
        OpenCL is an API to talk with the GPU, this thing allows you to write programs that will run on the raspi GPU directly.

        It is a module for a compiler called LLVM https://en.wikipedia.org/wiki/LLVM that allows it to write code meant to be run on the Raspi GPU.

        The most obvious use of LLVM in this case is for graphics drivers (LLVM compiles shaders for most GPUs around), but also for other specialistic applications that might want to run on the GPU.
        This has nothing to do with the GPU, but runs on the VPU, which is a specialized core for decoding video encoded in various formats: MPEG-2, h.264, VC-1, ...

        Comment


        • #5
          From what I understand, the VPU (part of Video Core IV) is basically the core of the pi, and the ARM is just a co-processor!
          I think the open source mesa drivers for VC4 just use the QPUs (a QPU does shader execution and can be used for GPGPU)
          directly and don't mess much with the VPU. (I think)

          Currently a blob (start.elf on the SD card) runs on the VPU.
          This blob even has a hole OpenGL ES driver built into it!

          This new LLVM backend should make it easer to hack the VPU.
          Maybe even replace the blob eventually?

          note: I am new to a lot of this stuff, and could be wrong about some things

          Comment


          • #6
            Originally posted by triangle View Post
            From what I understand, the VPU (part of Video Core IV) is basically the core of the pi, and the ARM is just a co-processor!
            I think the open source mesa drivers for VC4 just use the QPUs (a QPU does shader execution and can be used for GPGPU)
            directly and don't mess much with the VPU. (I think)

            Currently a blob (start.elf on the SD card) runs on the VPU.
            This blob even has a hole OpenGL ES driver built into it!

            This new LLVM backend should make it easer to hack the VPU.
            Maybe even replace the blob eventually?

            note: I am new to a lot of this stuff, and could be wrong about some things
            You're pretty much spot on there. I'm not sure what the intentions of this project's maintainer are, but if someone can get GCC to compile VPU code (and the MMU is good enough) then maybe there can be a port of Linux to the VPU that can communicate to the ARM processor and maybe even run mesa under it...

            Comment


            • #7
              More infos here: http://crna.cc/

              Comment


              • #8
                Originally posted by daemon32 View Post

                You're pretty much spot on there. I'm not sure what the intentions of this project's maintainer are, but if someone can get GCC to compile VPU code (and the MMU is good enough) then maybe there can be a port of Linux to the VPU that can communicate to the ARM processor and maybe even run mesa under it...
                WAAAT? Why that?

                Comment


                • #9
                  Originally posted by adler187 View Post
                  This has nothing to do with the GPU, but runs on the VPU, which is a specialized core for decoding video encoded in various formats: MPEG-2, h.264, VC-1, ...
                  I think that's a little bit inaccurate - video encoding/decoding for most formats is mostly handled by dedicated video hardware blocks in the VC4 chip (and those blocks are controlled by the VPU, with the VPU also doing some low-cost bits of computation the dedicated hardware doesn't handle), just like 3D is mostly handled by the V3D hardware blocks (traditionally controlled by the VPU, with the VPU also doing some stuff like format conversions), and just like the camera/ISP and display are mostly handled by other blocks.

                  So the VPU is primarily there to control and coordinate all the different types of multimedia hardware, not specifically video; and secondarily it's a sort of backup for various kinds of image processing (using its SIMD vector instructions) for all the different multimedia features where the dedicated hardware doesn't go far enough (because of cost or changing requirements or a need for flexibility).

                  Originally posted by daemon32 View Post
                  if someone can get GCC to compile VPU code (and the MMU is good enough) then maybe there can be a port of Linux to the VPU that can communicate to the ARM processor and maybe even run mesa under it...
                  The VPU doesn't have any MMU at all (except a thing that remaps just the top couple of address bits, if I remember correctly). And on the modern Pis, the 400MHz VPU is not going to perform well against a 1.2GHz quad Cortex-A53 - its only real benefit for 3D is that it's running an RTOS so it can service the hardware interrupts more reliably than Linux would, and you'd lose that by running Linux on it.

                  Comment


                  • #10
                    Originally posted by starshipeleven View Post

                    WAAAT? Why that?
                    For stupid fun.

                    Originally posted by Philip View Post
                    I think that's a little bit inaccurate - video encoding/decoding for most formats is mostly handled by dedicated video hardware blocks in the VC4 chip (and those blocks are controlled by the VPU, with the VPU also doing some low-cost bits of computation the dedicated hardware doesn't handle), just like 3D is mostly handled by the V3D hardware blocks (traditionally controlled by the VPU, with the VPU also doing some stuff like format conversions), and just like the camera/ISP and display are mostly handled by other blocks.

                    So the VPU is primarily there to control and coordinate all the different types of multimedia hardware, not specifically video; and secondarily it's a sort of backup for various kinds of image processing (using its SIMD vector instructions) for all the different multimedia features where the dedicated hardware doesn't go far enough (because of cost or changing requirements or a need for flexibility).


                    The VPU doesn't have any MMU at all (except a thing that remaps just the top couple of address bits, if I remember correctly). And on the modern Pis, the 400MHz VPU is not going to perform well against a 1.2GHz quad Cortex-A53 - its only real benefit for 3D is that it's running an RTOS so it can service the hardware interrupts more reliably than Linux would, and you'd lose that by running Linux on it.
                    Huh, I read somewhere that it did have an MMU... And interrupts are the only reason communication from ARM -> QPU is slow?

                    Comment

                    Working...
                    X