GPU documentation

Hi,

Looking through the documents and couldn’t see much on the subject.

What is the state of the GPU documentation / acceleration on different ports?

I gather the datasheets for Broadcom’s VideoCore IV are NDA only. What about for the OMAP 3/4 boards – are technical sheets available? A brief Google search didn’t pull up anything useful :-(.

Do we have interfaces into accessing these GPUs documented anywhere? How much hardware acceleration is currently done?

Apologies if these are answered elsewhere – just haven’t seen it (or they are buried in the midsts of time when an entry into the documentation may be nice :-).)

I gather the datasheets for Broadcom’s VideoCore IV are NDA only.

This is correct, but due to the unique nature of the CPU/GPU relationship in the Pi, Broadcom have actually been able to publish all of the source code to the ARM side GPU drivers. So if we ported this to RISC OS we’d get a fully working OpenGL driver.

What about for the OMAP 3/4 boards – are technical sheets available? A brief Google search didn’t pull up anything useful :-(.

OMAP3 & OMAP4 use PowerVR GPUs, which as you’d expect are under heavy NDA. Although there now seem to be quite a few open source GPU drivers for common GPUs (see list on wikipedia), it looks like a PowerVR one hasn’t happened yet (and the FSF’s attempt at creating one seems to have vanished from the web?). So our best chances of getting a driver working on RISC OS are probably to create a wrapper layer to allow us to load the original Linux driver binaries.

Iyonix: There’s IyonixMesa, but unfortunately it doesn’t work with the GeForce FX cards that started shipping with later Iyonix models. However it looks Nouveau has advanced a bit since I last checked up on it, and now appears to support 3D acceleration on FX-series cards, so if anyone’s feeling brave it could be interesting to try porting that to RISC OS.

Looking through the HAL documentation – is there a block of GPU registers mapped into memory? Or is there another way to access the GPU registers?

There are two ways of communicating with the GPU:

1. There’s a low-level mailbox interface. During startup the HAL uses this to get some configuration info (e.g. RAM detection), and at runtime the video driver uses it to control the main framebuffer. See s.Messaging for the HAL code, and s.BCMVideo for the video driver code (specifically SendMBMessage). There’s also a spec here on the Raspberry Pi github pages covering all the calls that are available via the interface.
2. There’s the higher-level VCHIQ interface. This is used for audio, hardware video overlays (including mouse cursor), video decoding, and almost certainly 3D acceleration. There isn’t any documentation for VCHIQ (or there wasn’t the last time I checked), but our VCHIQ module is pretty much a straight port of the Linux VCHIQ kernel module – so it should be fairly straightforward to adapt code written for the Linux driver (like the GL stuff will be) to work with our module. RISC OS sources are here, and the latest Linux sources seem to be here. Note that the userland github repro (where the GL drivers are) only seems to contain the sources for the userland VCHIQ library, not the kernel module (unless I’m missing the full sources hiding somewhere?)

Hmm – I’ve had a good look through the linked sources, and to be honest I’m really not much the wiser.

Most of the VCHIQ ‘source’ seems to be headers to the firmware – and as you say undocumented headers at that.

From there, within the headers there seem to be functions for setting up queues for example. But no indication as to what the command set to put into those queues might look like. Or indeed much of a clue about how to use them.

I was sort of hoping to be in the position to understand how to, for example, use the driver to plot a rectangle – which from this I’m none the wiser :-(.

Does the GraphicsV 14 call to read the EDID work on the Pi?
The call information talks about IIC, however on the Pi you talk nicely to the GPU for that information…

I wrote some code to bang the GPU’s mailbox directly, but it hangs the system (Caps Lock works, nothing else seems to) which suggests to me that I am not correctly emptying the mailbox and, as such, blocking it for any other accesses. Oops!
But, then, a proper datasheet would be more helpful than a couple of half-finished wiki pages… :-/ What is the actual mechanism for reading data back from a mailbox? <sigh!>

Today Broadcom have released the VideoCore IV documentation and source code

It’s targeted at a different device (the BCM21553) but the Pi foundation are offering a $10000 bounty for the code to be ported to the Pi.

Some useful analysis of the code release. See also the VideoCore reverse engineering effort (and its wiki) and also the related QPU effort

There’s lots of interesting things that could happen with this, beyond making better graphics drivers. For example, imagine if a VNC server were implemented on the GPU side. That could provide hardware VNC irrespective what OS it runs. Or perhaps the GPU could be used for acceleration like network or crypto. Another idea would be to move some of the USB stack into GPU land which would take away CPU load. Lots of possibilities.

Edit: ah, I overlooked the thread where this was already posted.

Or perhaps the GPU could be used for acceleration like network or crypto.

I’d just settle for XviD/H.264 transcodes faster than my slowpoke Atom netbook can manage – an accelerated ffmpeg would be lovely. I know it isn’t exactly fair to compare an 800ishMHz ARM to a 1.6ishMHz dual-core Atom; but the truth is in the using of it. Running RaspBMC, 720P is no problem and the Pi copes quite well with no adverse effects. The x86 with Intel’s lovely GPU… just about manages with two decoder threads, struggles with higher bandwidth stuff without the loop filter disabled, and needs a fan hack to prevent the CPU temperature jumping from 58ish to the low 70s. The Pi, by comparison, with no cooling whatsoever, reported a rise in temperature of a single degree, but that could just have been an ambient variation.

So, yes, an accelerated video transcodes would be quite nice. ;-)

[test files: H.264/FLV of Gangnam Style from YouTube, 720P, with overlaid subtitles; H.264/MKV of Fractale episode 10, 720P, and if you’ve seen the OP you’ll know that was a cruel test – the eeePC failed miserably; H.264/MP4 720P from my phone, phone handheld as I cycled up the lane; H.264/MOV 1080P from my iPad, playing with the cats outside – the Pi failed, but since audio worked flawlessly I rather suspect the HDMI→VGA dongle is the problem, the eeePC managed about one frame a second if I was lucky!]

Edit: ah, I overlooked the thread where this was already posted.

And I overlooked the thread where it should have been posted! Thanks for the informed additional links. Cheers :-)