Qualcomm Makes Open-Source 3D Snapdragon Driver

An anonymous reader writes "Qualcomm today posted the source code to a Linux kernel driver for 2D/3D support on its OpenGL ES Core found on Snapdragon-based phones like the Nexus One. The company is trying to get this driver into the mainline Linux kernel, but it turns out that the user-space driver is still not open source, which has resulted in some problems already. The ongoing discussion can be found on FreeDesktop.org."

Comments

This is the great thing about Android.

[GNUALMAFUERTE]

It's not only a great system, and it's FS, it's also going to drive other companies to do the same, and open their code.

Re:This is the great thing about Android.

[ThePengwin]

The Term FOSS would have been better :)

Re:This is the great thing about Android.

[marcansoft]

Too bad this driver isn't open source. Sure, the kernel component might be, but as the announcement itself clearly states, kernel 3D drivers are really just resource managers. The real driver lives in userland, and that part isn't open source. Phoronix is hoping it will be, but I've seen no clear indication of that.

Don't hold your breath. Nothing says the userspace component will be open sourced. Without that, this isn't even remotely an open-source 3D graphics driver. This is just an attempt to take advantage of a mainline driver being constantly updated and maintained with the kernel, without actually releasing the source to the part that matters (the userspace part).

Re:This is the great thing about Android.

[hairyfeet]

That brings up a good question I've always wondered, which is "how far do you push the "Open" part of FOSS"? I mean to hear RMS tell it anything short of GNUSense isn't really "free" because they allow binary blobs and firmware, but at the same time if a company says "take it or leave it" how many times can you say "leave it" before you don't have enough devices to worry about? I mean Nvidia will give you nothing but a binary blob, yet here on /. we hear guys say time and time again to stick to Nvidia even though ATI has opened their specs, so at what point does the Linux community decide features or performance is worth more than freedom?

As for TFA, unless the telecos change their business models I doubt you'll be getting much "free" in a handheld, as crippling phones and locking the hell out of their networks is pretty much SOP, and I just don't see that changing. After all if your phone was truly "free" you could have hackers finding a way to allow tethering, or turning on the features the telecos killed, and they certainly wouldn't like that. With something like PMPs I can see having freedom because other than Apple's walled garden of iTunes most manufacturers don't care what you do with the device once they have your money, as long as they don't have to support your hacks. But the telecos want to keep getting your money by forcing you to buy "premium features" which are often already on the phone and simply turned off. And I really don't see them giving up that golden goose for users freedom any time soon. So really, what good would having the GPU open really be if the rest of the device is locked tighter than a nun's thighs?

Re:This is the great thing about Android.

[marcansoft]

I have no problem with both open and closed source softwre. I have an Nvidia graphics card and use their binblob drivers. As long as you trust the manufacturer to deliver quality drivers, there's no problem with that. The issue arises when people try to mix together open and closed software in order to reap the benefits of open source without giving anything practical in return.

In this case, Qualcomm are trying to avoid the mess of maintaining binary kernel drivers, while not actually providing an open source driver for their hardware. This shouldn't fly. They can either deal with kernel maintenance and binary modules themselves, or open their entire driver so the open source community can hack it, improve it, and get into a state where it can be merged into the kernel.

If this "open source" driver were merged into the kernel, it would still be tied to the closed source usermode binblob. That means the ioctl intervace is untouchable, which means pretty much nothing can be fixed (as far as the interface goes) without Qualcomm's cooperation. It also means that kernel developers have to trust the binblob, and the lack of specs also means that the behavior of the kernel drivers (e.g. their security) cannot be reasonably analyzed. This isn't good.

In fact, Nvidia have open sourced small portions of their drivers (the settings GUI and part of their kernel abstraction shim, at least), but they are maintaining these themselves. Really, there's no problem with partially open source drivers, you just can't expect open source developers to maintain the open source part for you.

Re:This is the great thing about Android.

[SimonTheSoundMan]

Fresh Off the Slave Ship?

Re:This is the great thing about Android.

[Svartalf]

The driver stack for the FOSS side is just now beginning to learn how to crawl properly- something you need to do before you can walk or run.

Previously, we'd reverse engineered the stuff. Based on what I've learned doing work for one of the Big Two (that'd be AMD or NVidia...), they're barking up the right tree, doing things in the large the same way they do things within the driver. When the community gets to those first few stumbling steps instead of crawling around, the speed of development will increase- and AMD's stuff will suddenly become quite valuable to anyone on Linux or other FOSS OS.

Like we've been told before in the past- doing 3D drivers isn't exactly an easy thing to do. It takes some time before you can get to the same level of support we see with the proprietary drivers from NVidia and AMD. Unfortunately, you either have to choose pretty robust drivers, slightly less robust/speedy hardware, coupled with closed drivers- or choose much more unstable drivers (some people have GREAT results with AMD's stuff, I've got decent results with some issues in my case- but some have pure HELL with the drivers in question...) and the promise of 6-12 months down the line having 60% of the peak performance with an open source driver, coupled with the promise of seeing as much as 85% of the peak performance or more in another 12-24.

Many will choose the shiny solution that works right now. Some don't need and can't afford to fidget with the hardware to make it work and will buy something for business that will work right now (AMD's stuff is less robust in the laptop space until recently- which translated into an NVidia purchase on my i7 laptop I'd bought a while back.

If AMD's closed source solution was a full-on winner (it's not...) there'd be a lot less people buying NVidia right now because they opened up and it's coming together for everyone on that space, albeit slowly.

It's nice to see kernel hackers understand ...

[GNUALMAFUERTE]

Where they stand, and the power they have right now.

FTFA:

We are going to start to see a number of companies in the embedded
space submitting 3D drivers for mobile devices to the kernel. I'd like
to clarify my position once so they don't all come asking the same
questions.

I hope they use this new found power wisely.

Re:It's nice to see kernel hackers understand ...

[MostAwesomeDude]

It's not new-found. This has been policy for a long time, and has been applied to e.g. OMAP SGX and Poulsbo/Moorestown patchsets. This is more of a link to which we can direct people asking stupid questions on IRC.

FUCK THEM MAN FUCK THEM TO TEARS ALREADY !!!!!!!!

[Anonymous Coward]

What is it with these ME-TOO asswipe corporations that show the tits but keep the pussy behind a chastity belt?

This is for you RIM, Nokia, Microsoft and Apple

[bogaboga]

Companies including RIM, Nokia, Microsoft and Apple should watch out for Android with its Linux roots. Development appears to be fast. At this speed their lunch is at risk.

What appears to be holding Adroid is "bad" publicity on battery life, the poor organization of the Android Market including poor quality apps and the [subjective] poor user experience on high end phones.

As a matter of fact, the state of the Android Market is severely anaemic because whereas apps in this market are said to number about 75,000 now, having a look over here does not show any figure near that!

To make matters worse, there is no provision for searching for an app whose name you might not remember well. What surprises me is that the market is owned by a company (Google) which boasts of the greatest and best search engine in planet earth! Think about that for a moment.

Now before I get flamed, I know there is AndroLib. What I am talking about are efforts by the search giant Google.

Re:This is for you RIM, Nokia, Microsoft and Apple

[Microlith]

Companies including RIM, Nokia, Microsoft and Apple should watch out for Android with its Linux roots. Development appears to be fast. At this speed their lunch is at risk.

RIM and Microsoft are the ones who really have to be concerned. Apple will turn into a niche, though a very competitive one. Nokia however is pushing Symbian down the stack to their midrange and lower phones, reserving the high end for MeeGo, which holds to more "true Linux roots" than Android by being a common Linux stack from the kernel up through X.

That doesn't mean it's competitive, but it sure gives it one hell of a draw that many people lost once they realized Android was a Java-incompatible Java sandbox.

Re:This is for you RIM, Nokia, Microsoft and Apple

[dwater]

Also, I think the underlying issue in this story is about Open Source (rather than Linux), and I think even Symbian is more Open Source than Android is.

I say that mainly because of Symbian's open governance model - ie no one company has control. The same can be said of MeeGo, and Qt is heading that way too.

Symbian also gives you many more choices for development than Android - there's a whole wealth of programming languages to choose from.

In many ways, Nokia is really doing Open Source like very few other companies. I don't know if the upper echelons really get it (maybe), but the I'm certain many (majority even) of the engineers do - FOSS really is at the heart of the company.

Re:Compiz

[MostAwesomeDude]

So many possible replies, so little time.

"Sorry. I didn't know that it was our fault that your distro of choice didn't pick up DRI2 sooner."

"Well, if you ran Fedora, this wouldn't be a problem."

"Why DRI2? DRI1 is just fine for compiz, as long as your server supports AIGLX, or even *shudder* Xgl."

"Well, obviously you won't buy ATI again; it's AMD now."

">implying ARM processor manufacturers ever release 3D code or specs"

"Really? Compiz? Your killer app is compiz? Not Blender or WoW?"

"So I know this is gonna kill my karma, but..."

Brilliant move

[Weaselmancer]

Well, halfway anyways. Release the other half (the user space) part as FOSS and you'll be golden.

The biggest problem I've seen in embedded Linux is poor graphics performance. You have all this video acceleration that CE/XPe can take advantage of, and Linux doesn't get but a mere teaspoon of the graphics speed the hardware is capable of.

You really want to see your platform take off? Want your CPU sales to go through the roof? Give us something that is as accelerated as the Microsoft side of the equation. Give us the source. It won't hurt your sales. It won't help your competitors. Reverse engineering would take more time than actual R&D. Who wants to copy a video device that's already on the market when you can make better and faster by the next quarter anyways?

Seriously - this is the way to go. Release your driver source. All it can do is help move your product into more market spaces.

Command stream protocol?

[White Flame]

So nosing through the posted code, it seems like it deals with shuffling commands through to the chip, but I don't see any header files helping to define what data gets sent through the actual "issueibcmds" call. There's some gfx-level stuff in yamato_reg.h so I could be wrong.

I guess companies like this want to keep their trade secret optimization techniques in how they convert OpenGL state to chip buffer commands, but if they would open up the actual chip-level communications then the community could create their own open source OpenGL layers. I suspect there's a lot of command styles and user-space optimization techniques that could be reused across multiple chipsets, yielding a lot of benefit to true open source 3d hardware acceleration drivers. I just really don't understand their business case for not letting people develop new software to their chip, even if their proprietary driver stays proprietary.

Plus, WHERE ARE THE COMMENTS? Does nobody actually document their code anymore? This is your companies' public relation and an olive leaf to the Linux community for crying out loud! Show at least some semblance of competence in writing maintainable software!

Re:Command stream protocol?

[White Flame]

Ok, I shouldn't post that fast. ;-) It seems that kgsl_pm4types.h does at least describe the commands shipped off to the chip, so somebody willing to put the effort into banging away at it could generate actual high-level documentation on how to use the chip via trial-and-error and/or intercepting command buffers from simple OpenGL test programs through the userland blob through this driver.

Seeing such documentation exist with the code already would of course be the better situation, and I still don't see any barrier for Qualcomm to release that given as much as they've released now.

If we could only get kernel source to use this...

[doowod]

Drivers are nice and all, but you need a kernel to compile them into.

In the case of the Snapdragon-powered Sprint Evo, HTC still hasn't released kernel source after a month of distributing the binary kernel. Despite the fact that GPLv2 requires them to release the source along with the binary...

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

For the Nexus One, HTC waited around 6 months after releasing the phone to release the kernel source. The HTC Hero still doesn't have the most current source released.

It's sad to see that the manufacturer of flagship phones for every major US mobile phone carrier (other than AT&T) has no respect for the GPL and has reduced developers to reverse engineering Linux kernel sources, asking clueless customer service reps for a source release, and generally trying everything they can think of without getting any positive results at all.