[nickr]

http://www.theregister.co.uk/2014/02/28/...rce_driver

Broadcom has released open-source drivers and documentation for the graphics processor that's used in the Raspberry Pi microcomputer, among other devices.

"To date, there's been a dearth of documentation and vendor-developed open source drivers for the graphics subsystems of mobile systems-on-a-chip (SoC)," Eben Upton, a Broadcom technical director and Raspberry Pi Foundation cofounder, wrote in a blog post. "Binary drivers prevent users from fixing bugs or otherwise improving the graphics stack, and complicate the task of porting new operating systems to a device without vendor assistance."

I couldn't find a reference to this on the forum anywhere, if I am repeating something already posted, please delete my thread, or merge it or something.

[un1versal]

Great stuff, now if all vendors did this, a true wooa moment would happen in oss. I feel slightly more compelled to grab a PI now though clearly not for the 10k prize unfortunately as the only C I know is a letter in alphabet.

Broadcom here leading by example, lets not forget they worked with XBMC on Crystal HD card and iirc its also OSS drivers?

[nickr]

Then again the tech they use in rpi may be close to EOL. Braver if they released the code to their 4k hevc capable chipset - which if they don't have now, is surely in development.

[Ned Scott]

Nah, the Pi Foundation said it would be a few years before they consider updating hardware. The Pi might be "old" but it does what it does really well (XBMC wise, it preforms better than it did 2 years ago!), and part of the advantage of the Pi is a massive community all working on the same hardware. That's why it constantly gets better results than hardware that is technically better.

[un1versal]

My feelings exactly Ned, though for that last part, it makes me slightly sad,

[Basje]

If they get the code ported, what would that mean for XBMC? Would we get an even better experience? And what parts would benefit from it?

[un1versal]

Ported to what? Releasing the drivers on opensource just mean all developers have access to them to make improvements, so for xbmc this could mean better hardware acceleration for media playback.

[Basje]

Ported to what? Releasing the drivers on opensource just mean all developers have access to them to make improvements, so for xbmc this could mean better hardware acceleration for media playback.

I meant ported to the actual chipset that is in the pi. The one that was open sourced was closely related and the pi foundation actually had 10000$ for those developers that port it?

[un1versal]

No, that was 10k to whoever gets Quake III to work with at least 20fps. It has nothing to do with porting, afaik.

"As an incentive to do this work, we will pay a bounty of $10,000 to the first person to demonstrate to us satisfactorily that they can successfully run Quake III at a playable framerate on Raspberry Pi using these drivers," the Raspberry Pi Foundation said in a separate blog post.

For purposes of the contest, "a playable framerate" means a minimum of 20 frames per second.

The mention of porting was only as a passing reference as an example why binary closed source is not good when porting to e.g a different OS without vendor assistance.

[awp0]

Hmmm, I thought the $10,000 was a reward for the first person who can take the newly open sourced drivers and enhance them well enough to play Quake 3 at a reasonable frame rate.

Anyway, it would be great if this translated to benefits in XBMC. Though, it seems like the biggest struggles are in the area of UI performance, which I think is primarily bottlenecked by CPU speed and storage read performance. Though I'll defer to the experts.

Edit: Yeah, what universal said 2 minutes before me.

[popcornmix]

The 3d graphics driver for the Pi currently runs mostly on the VPU (a processor on the GPU).
There's not much point in releasing that source, as the compiler/debugger tools for the VPU are not freely available.

What's been released is the 3D graphics driver source code for a similar chip (with the same 3d hardware) where the driver runs on the ARM.
Running on the ARM makes building/debugging/developing much easier and so this is an easier starting point than releasing the Pi's VPU code.

The hope is that the ARM side driver is made functional and can be used as a replacement for the VPU based one.
This driver may have better or worse performance than the closed source one (probably worse initially).
The key thing is if someone wants to improve it, or add new feature, or fix bugs, then that will be possible.

There's also now a full register level spec for the 3D hardware (including the SIMD processors that run GL ES shaders),
which means people could run other (non-3D) code on it - e.g. an OpenCL compiler could now be written,
which could be useful for various optimisation tasks.

We recently released FFT code that ran on this SIMD procesor, which is about 10 times faster than FFTW running on the ARM.
In theory other functions could now be produced to accelerate parts of (currently unsupported) codecs, or do audio processing, or video processing or whatever.

Whether people will choose to work on features like this, I don't know, but it is now a possibility.