Live data from Hacker News

LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

github.com

21–30 of 54 posts

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#21
post #7

You can run C code on GPUs? I don't know anything about GPUs, but I thought they had a completely different programming model that requires different programming languages and paradigms.

VPU is not a GPU, it was designed for stuff like video decoding. It is just a simple RISC with some SIMD instructions.

QPU is a different beast, in VC4 it cannot even run arbitraty C code. In VC5 it can, but inefficiently.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#22

Earlier quoted context omitted.

Lessen the burden from the relatively weak ARM core used as CPU. The VPU seems very potent.

The RPi can handle playing back video (1080p) very well. Raspbian comes with omxplayer which uses the GPU to play video.

I know, I meant for other tasks (people mentioned DSP like logic).

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#24

What can you do with this?

To elaborate, I made this to develop an open source VPU side bootloader for Raspberry Pi because I was unhappy with the state of other C compilers targeting VC4 (I explained why in my blog). I haven't had the time to work on my firmware recently due to IRL events so I decided to publish the compiler. Not publishing any of the firmware work yet since it can't boot ARM yet (but SDRAM init reliably works across all boar…

Thanks for making this work! I'd given up on the LLVM backend completely due to showstopping issues I couldn't resolve, and had assumed it had vanished into the aether. Glad to know you found it useful!

Regarding the boot loader, have you seen my piface boot loader? http://cowlark.com/piface/ It sounds like what you have is way more sophisticated, as I never got SDRAM init working properly, but you never know --- there might be something useful there.

I was actually considering having another go at a VC4 compiler, this time with pcc; there's an OS I want to port. I'm really happy to know that I no longer have to!

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#25

Earlier quoted context omitted.

To elaborate, I made this to develop an open source VPU side bootloader for Raspberry Pi because I was unhappy with the state of other C compilers targeting VC4 (I explained why in my blog). I haven't had the time to work on my firmware recently due to IRL events so I decided to publish the compiler. Not publishing any of the firmware work yet since it can't boot ARM yet (but SDRAM init reliably works across all boar…

Thanks for making this work! I'd given up on the LLVM backend completely due to showstopping issues I couldn't resolve, and had assumed it had vanished into the aether. Glad to know you found it useful! Regarding the boot loader, have you seen my piface boot loader? http://cowlark.com/piface/ It sounds like what you have is way more sophisticated, as I never got SDRAM init working properly, but you never know --- the…

...hilariously, I've just checked my email, and I see a two-day old message from someone who's just got my previous attempt at a VC4 compiler working. This one was with gcc:

https://github.com/puppeh/vc4-toolchain

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#27

How is this different than using gcc like they describe in this book https://jan.newmarch.name/RPi/ ?

The LLVM backend that has been written generates code that directly runs on the Videocore GPU, which also handles the early boot process. Your link is concerned with code that runs on the ARM core, and interfaces with the GPU via the existing code running on the GPU

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#29

It bugs me that LLVM targets are not properly 'plug in'. LLVM backends can be in a plugin, but you have to tell the frontend which target to use (so it can use the correct data-layout etc). Its the frontends that don't support plug-in targets. Clang, for example, hardcodes the supported targets. A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-…

"A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-of-tree targets :( Have you considered this is a deliberate decision, with a goal of having most targets in-tree? :)

Why is this beneficial? It means you need to change several repositories to add one target triple. This may be a win in terms of in-tree stability, but it reduces accessibility to everyone else.
Post reply on HN