Raspberry Pi ARM-side GPU drivers open sourced

http://www.raspberrypi.org/archives/2221

Now that’s big.

Time for IyonixMesa to have VideoCore support added?

I hope it can be the start of a trend (and what a way for Broadcom to put their SoC on the map as a development platform). I hope a revised datasheet will follow. ;-)

Although at a cursory glance I think that repository contains everything we need for a GL driver and some other useful things (e.g. the sources to the tvservice binary so we can change the actual display mode of the monitor), they still seem to be missing a fully BSD licenced version of the VCHIQ sources :( (What’s in that repository is just the sources to the userland library, not the kernel library which does all the real work)

I hope it can be the start of a trend (and what a way for Broadcom to put their SoC on the map as a development platform).

It’ll be a bit of a tricky trend to follow, unless other manufacturers start going down the “fat GPU” approach that Broadcom are using. Remember that none of the CPU graphics drivers actually talk to the graphics hardware directly – they just package up the commands and send them off to the closed-source OS/firmware running on the GPU.

Although there is a GPLed VCHIQ it seems? Meaning there’s two valid approaches:

Cleanroom it
Wrap it in a manner that allows it to be distributed without infecting the rest of the system

Also, as far as the SoC being popular for development overall… I’m not certain of it, given how weak the CPU is on that chip. It’s a GPU with an ARM11 taped to it for light duty application work that needs a lot of graphics power.

Strap a Cortex-A9 or A15 or two to it, and then we’re talking.

Although there is a GPLed VCHIQ it seems?

Yes, and that’s what we’re currently using. Downside is that it means we need to softload it during the boot sequence, so some features (sound, hardware pointer) aren’t available until later on.

I’m not certain of it, given how weak the CPU is on that chip.

Funny, looking at the benchmarks, while it gets its backside kicked with the OMAP4, it holds its own fairly well against the OMAP3. [granted, the test case was not OMAP optimised, but then this might be the case in general…]

It’s a GPU with an ARM11 taped to it for light duty application work that needs a lot of graphics power.

This is somewhere RISC OS might, with suitable drivers, be good for a media playback platform. RISC OS is really simple, and while this can mean bad things, it also means we don’t suffer the bloat and lethargy of a typical Linux distro; plus it is a lot easier to bang on the hardware under RISC OS (no need to grovel to the kernel). All in all, for a lightweight system to play media files, there could be something here… IF… sufficient access to the GPU is available to allow codecs to be created/ported.

Strap a Cortex-A9 or A15 or two to it, and then we’re talking.

Funny thing is, that may come if the RPi does well enough. I think people were taken aback by the demand, and certainly it seems to me as if the RPi foundation used a end-of-line lower-spec part possibly because it offered enough features without costing too much. The first I heard, Broadcom had no intention of releasing any documentation. Then a sort-of datasheet arrived. Now this.
Who knows, maybe behind the scenes somebody is working on the viability of keeping most of the chip as-is but hooking in a higher spec CPU, for a forthcoming RPi model C? [surely that would have to be the Raspberry Master?]

they just package up the commands and send them off to the closed-source OS/firmware running on the GPU.

Isn’t that how GPUs normally work these days?

Isn’t that how GPUs normally work these days?

Perhaps, but the VideoCore is the first one I’ve seen that works at such a high level. Judging by how lightweight that userland repository is, I wouldn’t be surprised if they even have the shader compiler running on the GPU!

Would this make my bountry regarding OpenGL hardware support easier (at least on the RPi) compared to the OMAP situation ?

Rick: I’m not disputing that this is a good chip for RISC OS (now it DEFINITELY is a great chip for that), just saying that the CPU portion is rather weak for the wider embedded development (think Linux and the BSDs) that you suggested earlier.

Rick: I’m not disputing that this is a good chip for RISC OS (now it DEFINITELY is a great chip for that), just saying that the CPU portion is rather weak for the wider embedded development (think Linux and the BSDs) that you suggested earlier.

I think Rick was rather working on the basis that most embedded systems don’t actually need much of a singing dancing OS and that even Linux is basically major bloat when it comes to driving an ARM core.

For the user of an embedded device, who doesn’t see the OS, they would be impressed with the speed of startup, maybe see the ripple of text in the boot and then use the device via the presented GUI.
The GUI here being some modified “desktop”

that even Linux is basically major bloat when it comes to driving an ARM core.

My PVR, a Neuros OSD running on a TMS320DM320 (~200MHz ARM9 with ~100MHz Cxxxx DSP) contains 16MiB Flash. When the firmware, which is a stripped-down debian plus closed-source codecs/libraries (Ingenient), changed from using NanoX to Qt4 (something to do with it being easier to create custom widgets, I don’t really know Qt4) the firmware overflowed the 16MiB and so Neuros needed to hijack the CF card to set it up as a mounted device for yet more bits of the firmware.
I think it is about 20Mb all in.
And Qt4 itself, running on PortableUbuntu (basically Ubuntu within Windows) fails to compile Qt4 even when I’ve reserved half a gigabyte for the Ubuntu thing and am running nothing except the compiler in a terminal window.
It is horribly horribly bloated. That a fairly straightforward UI for a PVR takes around 22Mb and a good 2-3 minutes to boot… it actually makes my head hurt.

I really don’t think Linux is suited for lower-end embedded devices. For a mobile phone, perhaps (although those take an eternity to start up too); but for something simpler where there is less demand for rigorous inter-process protection, running a server class operating system is just a whole heap of overkill.

If you’re interested in seeing the OSD’s UI, take a look here: http://www.heyrick.co.uk/blog/index.php?diary=20100411
And I have recorded some example videos (same thing, various quality settings, at: http://www.heyrick.co.uk/blog/index.php?diary=20100410
[ignore the bit about the interference pattern, I know know that the long ‘video’ lead is always connected to the video decoder chip, so I have to be careful to shield it when using the s-video input else it’ll pick up noise and degrade the image]

Oh, and if you think you might like the movie, you’ll find a subtitled version here: http://www.youtube.com/watch?v=lK1dlxeWYxQ
Cute girl, big sword, over-the-top action… what’s not to like?

Or, if you don’t fancy the entire movie, at least take 10 minutes out of your day to enjoy the epic melee, especially when it turns into complete chaos. But hang around, there’s more to come – http://www.youtube.com/watch?v=lK1dlxeWYxQ&feature=player_detailpage#t=6770s [as for the effeminate bloke in white…uh…too much explaining… he’s The Big Bad]

All in all, for a lightweight system to play media files, there could be something here

I’ve been trying RaspBMC, it plays 1080 content quite happily, although it stutters badly with big files – BD size. I suspect the issue is the USB performance, hopefully this will improve.

If RISC OS ever gets this ability, that would be excellent. (and of course we wouldn’t have to worry about files with too big a bandwidth, because they won’t fit on ADFS or FAT32 anyway :) )

Already RISC OS is gread for audio replay. (internet radio especially.)

Interesting what Eben had to say in reply to comments on Slashdot:

That’s a fair observation. We’re lucky that, with firmware installed, the VideoCore GPU exposes a much higher-level interface to the ARM side than some other architectures. This has allowed us to provide a viable, useful open source stack while also addressing Broadcom’s (completely legitimate) interest in protecting the fine detail of the underlying IP from competitors and patent trolls.
To help people get the most out of this, we hope to sponsor some efforts to formally document the interface exposed by the GPU over the next few months.

http://hardware.slashdot.org/story/12/10/23/2342201/arm-code-for-raspberry-pi-goes-open-source-video
(transcript available)

Actually, looks like there already is a VideoCore 4-based chip with a dual Cortex-A9 strapped to it: http://www.broadcom.com/products/Applications-and-Multimedia-Processors/Tablet-Application-Processors/BCM11311

Edit: Only a single VideoCore 4 core, though, so less graphics capability than the Pi.

I really don’t think Linux is suited for lower-end embedded devices. For a mobile phone, perhaps (although those take an eternity to start up too); but for something simpler where there is less demand for rigorous inter-process protection, running a server class operating system is just a whole heap of overkill.

I think I said elsewhere – I think the mobile phones have the wrong OS.
Something smaller and faster would be a good idea. Any candidates spring to mind?

Any candidates spring to mind?

A number. None of which would be RISC OS.

Also, a less enthusiastic response.

Something smaller and faster would be a good idea. Any candidates spring to mind?

Not RISC OS if that’s what you are thinking. RISC OS only really has two modes – user and supervisor. Modules that belong in userland load as supervisor. Memory protection and interprocess control is minimal. It suffices for our little OS but for a phone you want it all locked up solid. It wouldn’t be acceptable for an OS to trash itself on an errant task. I could write a module to intercept and log keypresses. It will load and run and have full run of the system with nothing saying “no!”. If I make an error, the OS won’t kill the module, RISC OS will instantly die (like those times I call a SWI in SVC mode and forget to stack LR!).
The concepts behind RISC OS might be suitable for a phone (I like also the idea of Minix’s reincarnation server), but as it stands, it isn’t suitable.
Now, an embedded device that doesn’t need to deal with critical user data (like the rights to text premuim numbers) and a variety of user-chosen “apps”… there, RISC OS might have an application.

Is the recently announced VideoCore IV source release going to be much use to the RISC OS work (not exactly the same chip)?

The sources mightn’t be for the same chip – but the doc is, isn’t it?

Is this the first publicly documented ARM GPU? If so – it’s a good step to take. Incomplete, but I suspect that they’re starting to get the idea of why documentation is a Good Thing.

Here’s hoping for the Pi’s third birthday, Broadcom will put together a TI-like datasheet for the chip. There’s just so much missing from the current one.
As for the GPU datasheet, what I was hoping would be described clearly is the system initialisation (as far as I can see, the GPU starts up the Pi and gets the ARM side running) and the mailbox method of communicating with the GPU (parts of which have been documented elsewhere).

Interesting!

There are some deficiencies with the current GPU firmware which we could probably fix if we used custom builds of it. E.g. we could get a better VSync interrupt than the one that’s currently offered; we could get rid of (or better understand) the points at which the mailbox interface will block when performing some framebuffer operations; we could rework the audio interface so that it works better with the way RISC OS does things; etc.

From a quick read, it looks like it’s the 3D side of the GPU that’s been documented, not the sort of low level info we’d need to bypass the blob or improve the RISC OS HAL. It does sound like they’ll be releasing more documentation in the future though, so there’s hope yet.

@Rick Murray (concerning Enhanced Pi) : “Pion” maybe? XD?