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.

[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.

[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.

[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.

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?

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.

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.

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.