LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

https://github.com/christinaa/LLVM-VideoCore4

by DHowett • 10 years ago

129 53 10 years ago

willvarfar4• 10 years ago

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-of-tree targets :(

krasin• 10 years ago

Out-of-tree targets for LLVM are generally a bad idea given how fast LLVM is changed. Every change could break the out-of-tree target, and being out-of-tree, there's no way the upstream developers could notice that.

sklogic3• 10 years ago

The other side of this approach is that when the mainline developers do not have much love to a particular platform, it is dropped altogether with little to no remorse - see the fate of Microblaze support, or even the good ol' C backend.

I wish we had a more stable API (maybe with a transformation layer) for the backends that may not probably need much of the new features. If LLVM had a maintained transformation layer from the "current" SelectionDAG to a stable one, it would have helped a lot.

DannyBee• 10 years ago

"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? :)

duaneb2• 10 years ago

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.

willvarfar4• 10 years ago

Which makes developing a large backend a lot of pointless busywork with patchsets touching parts of the codebase that really ought not need touching at all :(

(I'm someone who was stuck on 3.6 for ages because of the pain of keeping up with the trunk)

Joky• 10 years ago

It depends what you mean by "plugin": targets are configured at compile time. I don't think you can build LLVM and then dynamically load a backend as plugin.

willvarfar4• 10 years ago

You can load targets as plugins in llc :)

You cannot load targets as plugins in clang :(

pepijndevos2• 10 years ago

What can you do with this?

cnvogel• 10 years ago

This has some additional info from the author: http://crna.cc/

pepijndevos2• 10 years ago

I get that it's a compiler backend for the GPU of the Raspi, but what does that mean? I mean, can you compile arbitrary C code to run on the GPU? Is this for making a GPU firmware? Divers? games? Bitcoin miners?

agumonkey2• 10 years ago

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

ciroduran• 10 years ago

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

christina_b7• 10 years ago

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 boards). Once I get ARM working to some extent, I'll probably clean the code up and publish it too.

khedoros• 10 years ago

This is awesome! It seems like an important series of steps towards having a legitimately-open educational platform, rather than the somewhat asterisk-laden one that the Pi currently represents.

david-given3• 10 years ago

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!

hermanhermitage• 10 years ago

Great work. Very interested to see what you have going on the firmware side.

ashitlerferad2• 10 years ago

Will you be getting this merged into LLVM upstream?

haberman• 10 years ago

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.

TD-Linux2• 10 years ago

Yup. Check out the VideoCore ISA:

http://www.broadcom.com/docs/support/videocore/VideoCoreIV-A...

Note that in this case, the author is writing the bootloader firmware so performance isn't a major concern, though.

christina_b7• 10 years ago

This isn't the same, the document in question relates to the QPU ISA. The VPU ISA hasn't been officially documented but there were many projects that involved reverse engineering it. The VC4 ISA is documented here:

https://github.com/hermanhermitage/videocoreiv

The VPU is basically a general purpose RISC processor with some fancy vector instructions on top. In fact, most of the firmware that runs on it is written in C.

corysama• 10 years ago

They do. Or, at least they did. But, their capabilities have been improving rapidly for a couple decades now. To the point that shader compilers are integrating recent C++ features and some degrees of straight-up C++ support. You won't be able to magically run classic, single-threaded programs fast. But, you can start using advanced features you already know from CPU programming to write programs for the GPU.

sklogic3• 10 years ago

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.

nhaehnle• 10 years ago

Yes and no. You can definitely run arbitrary C code on AMD's GCN ISA if you're so inclined (and I expect every other modern GPU, but I know less about those...). There are all the usual assembly instructions, there are pointers, you can implement a stack, and so on. That doesn't mean that arbitrary C code will run fast :)

To fully use the computational power of the GPU, you have to make use of its parallelism. That means dealing with the fact that you can have hundreds or thousands of "waves" (things with a register file and a program counter) in flight simultaneously, and each "wave" corresponds to many (in AMD's case, 64) threads in the conventional sense.

It is the last part that makes the biggest difference compared to regular CPUs, because it changes how you have to think about control flow. If/else-statements must be compiled in such a way that the wave goes through both branches if the threads in the wave branch differently (if all threads branch the same way, you can of course skip the other branch).

The first part makes a big difference as well, of course. GPUs care far less about single-threaded performance, so there is no out-of-order or speculative execution, and the memory latency is high. When a wave has to wait, the latency is made up for by scheduling another wave instead. That is, there is a high level of what is called "hyper-threading" on the CPU.

mangix• 10 years ago

does this have opencl support now?

Narishma2• 10 years ago

No.

Narishma2• 10 years ago

VC4 is used in all the Raspberry Pi boards, not just the RPi 2.

0xdeadbeefbabe• 10 years ago

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

kenz0r• 10 years ago

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

mappu• 10 years ago

Outstanding!

Is it possible to use the LLVMLinux patches to run the kernel directly on the VC4?

q3k• 10 years ago

There's much more to porting Linux successfully than just having a working compiler for the target architecture.

christina_b7• 10 years ago

VC4 itself doesn't have a MMU per se, it supports very limited memory remap (like PPC BATs) so running a conventional kernel on it is probably not possible. Best bet would be to port an RTOS to it, but my current plan for my firmware pretty much involves halting the VPU once the ARM is running.

peteforde• 10 years ago

Could this be used to give more direct access to the Raspberry Pi Camera subsystem?

Would appreciate any pointers, no pun intended initially.

puppeh2• 10 years ago

I did GCC too, https://github.com/puppeh/vc4-toolchain.

christina_b7• 10 years ago

Yeah, I saw, I haven't looked at it in detail but I think yours probably works better than mine since you did comprehensive testing. My only tests involved compiling my own firmware code, but from what I can tell, it works well, I haven't ran into any bugs yet aside from what I outlined in the README.

The assembler/linker I'm using is not ideal, I want to get MC code emission working eventually. I saw that you mentioned limitations on ld/st, why not use lea for data?

For example:

  BB1_12:                                 # %sdram_clkman_update_end.exit2
	mov r0, 2114982312 # long
	ld r2, (r0)
	lea r0, .str8(pc) # PCrel load
	lea r1, __FUNCTION__.sdram_init_late(pc) # PCrel load
	bl xprintf

puppeh2• 10 years ago

No reason I guess, except it means an extra instruction. I thought about adding a flag for "large model" compilation, but it's not been a priority so far.

LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

Related Stories