GPU documentation
William Harden (2174) 244 posts |
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 :-).) |
Jeffrey Lee (213) 6048 posts |
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.
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. |
William Harden (2174) 244 posts |
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? |
Jeffrey Lee (213) 6048 posts |
There are two ways of communicating with the GPU:
|
William Harden (2174) 244 posts |
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 :-(. |
Rick Murray (539) 13806 posts |
Does the GraphicsV 14 call to read the EDID work on the Pi? 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! |
Theo Markettos (89) 919 posts |
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. |
Rick Murray (539) 13806 posts |
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!] |
Trevor Johnson (329) 1645 posts |
And I overlooked the thread where it should have been posted! Thanks for the informed additional links. Cheers :-) |