Become a fan of Slashdot on Facebook


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Looks like the heavy lifting is done elsewhere (Score 1) 91

The biggest advantage here is that if the "top side" interfaces change, or something needs to change with how the library is compiled (say against glibc for a stock linux platform vs bionic for android), that's pretty trivial to resolve compared with getting a handful or .so or .ko binaries. And yeah, it doesn't help you fix the firmware if the firmware is busted, but it's still an improvement over where things were before, so hey, progress.

Comment Re:Looks like the heavy lifting is done elsewhere (Score 1) 91

That's my hope. My issue with the purists is that it's not obviously clear why they want to see the microcode running on a proprietary RISC core inside the GPU, but not for example the Verilog. Stallman is one of the few people who has a self-consistent model of what he wants to be able to see, arguing that code which is "equivalent to a circuit" (i.e. in ROM) need not be made visible. Now we don't meet this criterion as our microcode lives on the SD card, but that's largely a cost and flexibility issue and we may yet go there to get the FSF endorsement.

I consider "ability to redistribute the firmware for use on the hardware it belongs to" totally reasonable, but I definitely fall into the more pragmatic camp.

From one point of view the cost to Broadcom to making this open source is not nearly the same as for the other GPU vendors -- I suspect this RPC glue is not among the crown jewels of Broadcom's IP

I should have kept some of my notes from those meetings :)

I'm sure they were highly entertaining. Once upon a time I was involved in arguing with a SoC vendor's lawyers over the ability to open source *GPIO* driver support... progress in these areas can be amazingly hard to achieve...

Comment Re:Looks like the heavy lifting is done elsewhere (Score 4, Interesting) 91

Yup. It's a common solution for video codec blocks, camera pipelines, etc, on ARM SoCs (open driver/library, closed firmware for the peripheral) -- less common for GPUs. I'm personally not at all offended by the "open drivers/libraries on host, closed firmware on peripheral" model -- it's a reasonable tradeoff and, as you point out, lets the vendors keep control over their secret sauce while still allowing for completely open software stacks on the host/AP side of the world. Apart from purists who want to have source for every programmable block on the SoC, everybody wins.

From one point of view the cost to Broadcom to making this open source is not nearly the same as for the other GPU vendors -- I suspect this RPC glue is not among the crown jewels of Broadcom's IP -- but from the viewpoint of someone who doesn't want to have to muck with closed binaries on the host side that are hard to debug, keep supported, adapt to changing APIs/ABIs, none of that matters -- the important bit is you get all the host side source.

Does this (or will this) support future / higher end parts using the same VideoCore architecture? It definitely increases my interest in the BCM SoC family if so...

Comment Looks like the heavy lifting is done elsewhere (Score 5, Informative) 91

Haven't had a chance to wade through all the code here, but it looks an awful lot like it's basically rpc stubs and glue (allocator, buffer management, etc) to remote the OGLES calls to the media processor, which presumably handles all the actual translation of OGLES API to whatever the internal architecture of the GPU looks like. Which is a perfectly reasonable approach, just not necessarily 1:1 with the other SoCs (which don't have a GPU block capable of speaking remoted OGLES, thus requiring knowledge of the underlying hardware "secret sauce" in the GL libraries or drivers on the host side).

Awesome that they're releasing this as open source rather than insisting on keeping it closed -- much easier to work with this way.

Comment Re:Trending in the right direction, room to improv (Score 2) 208

We've worked hard to never ship binary blob kernel drivers or any nonsense like that in Nexus devices, but yeah, proprietary userspace libraries are still needed for some peripherals against our best efforts. For wifi/bt it's generally just firmware that's downloaded to the device and not actual code that runs on the Linux side of the world. For the GPU all the vendors we've worked with on Nexus devices have provided GPL'd drivers for the kernel (resource management, etc), but provide closed opengl userspace libraries. Camera stacks vary -- the Nexus S didn't require any proprietary camera library goop in userspace iirc. I think we've been steadily improving the situation, but it's an uphill battle and I don't see a fully-open and also adequately performant GPU/opengl solution on the horizon yet.

Comment Re:When will the Linux layer be replaced another O (Score 2) 202

By Google? Highly unlikely that we'd ever do that. We're pretty heavily invested in the Linux kernel and it's been working well for us in Android.

By some other entity? Could happen, but the mid and lower layers of the Android stack depend pretty heavily on running on a Linux kernel. It'd be a bunch of work for questionable gain.

Comment Re:Is this the same source code? (Score 3, Informative) 203

Yes, the ICS tree that will be released to AOSP is the same code used to do the build for Galaxy Nexus (among other products).

Instructions on building for Galaxy Nexus will likely end up here (alongside Nexus S):

The handful of closed source userspace pieces necessary (some firmware, the hardware opengl libraries, samsung radio library, etc) will end up here:
(please disregard the unfortunate use of "drivers" here -- all the kernel drivers are GPLv2, none are closed source)

What's not included is the Google Mobile Apps (gmail, gcalendar, gtalk, maps, etc). These are proprietary Google applications, not part of the core Android platform (which consists of the lower level libraries, dalvik vm, framework libraries, services, core apps like phone, contacts, launcher, settings, etc, etc).

Comment Re:Umm.... (Score 5, Informative) 362

There are remarkably few binary blobs in Android lead devices (some OEMs add more proprietary goop to their own phones though).

Nexus S, for example, requires these pieces above and beyond the available open source userspace and kernel code:
- opengl userspace libraries (ImaginationTech)
- radio interface library (Samsung) -- glue between the Android Telephony stack and the Radio
- firmware for bt/wifi chip (Broadcom)
- GPS userspace library (Broadcom)
- NFC firmware / loader library (NXP)
- auto-calibration library for orientation sensor (AKM)

The closed pieces are available here, under a license that allows you to use them in your own builds, and even to redistribute (non-commercially) entire flashable OS images including them.

We continue to work to reduce the number of closed binaries needed on the lead Android devices. We have *never* shipped a lead device that includes any non-gpl/bsd kernel code.

Comment A "fitting home"? Really? (Score 1) 72

Seems pretty absurd to me. They just launched an Android-based platform with Amazon-customized UI, their apps already run on Android devices (of which there are quite a few out there), and they have their shiny new cloud-assisted browser, built on Android and EC2. What do they need WebOS for? How are they a "fitting home" for it?

Slashdot Top Deals

The absence of labels [in ECL] is probably a good thing. -- T. Cheatham