Qualcomm Makes Open-Source 3D Snapdragon Driver 84
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."
This is the great thing about Android. (Score:5, Insightful)
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: (Score:2)
FS=Free Software.
I wrote it's. That means "it is". I thought it was pretty clear.
Re: (Score:2, Informative)
The Term FOSS would have been better :)
Re: (Score:3, Funny)
Fresh Off the Slave Ship?
Re: (Score:2)
BTW, where is everyone? I was starting to wonder if the zombie apocalypse had started without me. Noone at /., and no new XKCD yet (It's already 00:08 EST).
Re: (Score:2)
Nobody can work because your RSS update interval is set to 100 milliseconds ;)
Re: (Score:1, Informative)
Re: (Score:1)
Only if it lets me use it with X.
I'd like to see the drivers opened such that I could have one less closed bit, but only having a kernel-side chunk open (or whatever bastardized process they have now) and the userspace stuff still locked to Android or whatever OS came on your device. Oh and to redistribute without being in violation of a license.
I'd love it if the PowerVR SGX drivers for my N900 had source. We could probably make them not suck and turn on VSync.
Re:This is the great thing about Android. (Score:5, Informative)
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: (Score:3, Interesting)
Re:This is the great thing about Android. (Score:4, Insightful)
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: (Score:2)
Re: (Score:2)
I'm using a laptop, so my choice of graphics chipsets is limited (though this one does use an MXM card, so I can conceivably switch it for another card at some point in the future).
Currently, the big feature that Nvidia has that ATI open source drivers lack is hardware video decode acceleration. As far as I know, ATI hasn't released specs for that part of their chips. I enjoy being able to play 1080p H.264 videos with little CPU usage (heck, even with a reasonably modern Core 2 Duo, you just cannot play som
Re:This is the great thing about Android. (Score:4, Interesting)
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.
Re: (Score:2)
You are not even merely a citizen of Texas, Texas is a state of people like you.
Re: (Score:2)
And I'm sure where you live is a State full of people just like you...
You went out of your way to accost someone for their Sig- which is a statement of the fact that I choose to claim and use my sovereignty as opposed to being a good little sheeple and being a source of money for those people that claim to be our leaders and those of business. I did nothing, nor stated anything remotely inflammatory, past that sig that might have even merited the response you made- especially not in my post you responded t
Re: (Score:2)
Sigh. No.
I mean that you are more than an anything of Texas, Texas is defined in terms of you, the people. Even citizen is a fairly passive term compared to sovereign for instance.
That said, if I did find your sig inflammatory I would not hesitate to attack it despite you having been discussing something else. If I have to look at it, I'll feel free to respond.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
As long as you trust the manufacturer to deliver quality drivers, there's no problem with that.
The problem comes when they don't. We've been waiting for Xrandr 1.2 support from Nvidia for 3 years. Everyone else has it by now, but Nvidia users are out of luck. So if you want independent rotation of monitors under one X display without breaking acceleration, you can't do that with nvidia.
Re: (Score:1)
Re: (Score:2)
It's nice to see kernel hackers understand ... (Score:5, Insightful)
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: (Score:3, Informative)
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.
Re: (Score:3, Insightful)
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 gonn
Re: (Score:1, Redundant)
So many possible replies, so little time.
Too bad all of them are stupid.
"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."
If you ran Fedora, you'd be alpha-testing features included in the OS when it is KNOWN they are not ready for prime time, but included anyway since Fedora is the alpha test environment for RHEL. Some of us are not willing to do this. I was a loyal RedHat user until RedHat went away, so I'm not saying this out of rpm allergy (although now that I've switched, I'm never going back.)
"Why DRI2? DRI1 is just fine for compiz, as long as your server supports AIGLX, or even *shudder* Xgl."
Did you ever use Xgl? First of all, it's over. Second, it worked better than AIGLX does. I got bett
Re: (Score:1)
If you ran Fedora, you'd be alpha-testing features included in the OS when it is KNOWN they are not ready for prime time, but included anyway since Fedora is the alpha test environment for RHEL. Some of us are not willing to do this. I was a loyal RedHat user until RedHat went away, so I'm not saying this out of rpm allergy (although now that I've switched, I'm never going back.)
You know, just about any modern distro has this now. Ubuntu, Arch, hell, even Slackware supports DRI2 for ATI out of the box now.
I've run Blender maybe twice and I will never play WoW. But I use Compiz features not just every day, but every hour. Expose and Shrink Windows are tied to hot corners and I use one or the other almost every time I switch windows.
Yeah, I bet you do spin the cube for hours at a time. You so l33t.
"So I know this is gonna kill my karma, but..."
If only.
Given who the GP is, I'm sure he has plenty of karma to burn. I might just have to find his posts and give him some more for making DRI2 and 3D work on my AMD/ATI card in the first place.
Re: (Score:2)
You know, just about any modern distro has this now. Ubuntu, Arch, hell, even Slackware supports DRI2 for ATI out of the box now.
So what you're saying is that it was an even dumber thing to say than I thought? Thanks!
Yeah, I bet you do spin the cube for hours at a time. You so l33t.
I don't use the cube, since its contents haven't been clearly visible on a fast flip since Xgl died and a slow flip is stupid. I use the wall. Expose and Scale Windows are both useful, unlike the cube. But go ahead and make pointless attacks.
Given who the GP is, I'm sure he has plenty of karma to burn. I might just have to find his posts and give him some more for making DRI2 and 3D work on my AMD/ATI card in the first place.
Now if only he could make the drivers not suck.
Re: (Score:2)
Now if only he could make the drivers not suck.
Bug number, please. I'm not CC'd to all ATI bugs, just ones pointed to me or assigned to the DDX. Or did you just want to attack me again?
Re: (Score:2)
Bug number, please. I'm not CC'd to all ATI bugs, just ones pointed to me or assigned to the DDX. Or did you just want to attack me again?
I meant it more as an attack on AMD/ATI in general. I've been reluctantly using AMD video chips in a variety of contexts since the Mach32 and have had driver-related woes with all of them. There is literally no ATI video solution I have EVER used that didn't cause me some kind of problem, and always clearly related to the functioning of the driver.
My latest problem with ATI graphics is failure of the R2xx video in the R690M chipset to produce video with the 'ati' driver without trashing. It mostly trashes o
Re: (Score:2)
"Really? Compiz? Your killer app is compiz? Not Blender or WoW?"
Not necessarily Compiz, but a compositing manager lets you offload a lot of work to the GPU and improves power consumption. In X11 using the core protocol, moving a window requires all of the windows that are exposed by the operation to redraw the exposed portion. On a mobile device, this is burning CPU cycles (and therefore battery) for something that is just duplicating work. In contrast, with a compositing manager running the app only needs to redraw when something changes. The resulting window is st
Re: (Score:2)
"Really? Compiz? Your killer app is compiz? Not Blender or WoW?"
Not necessarily Compiz, but a compositing manager lets you offload a lot of work to the GPU and improves power consumption. In X11 using the core protocol, moving a window requires all of the windows that are exposed by the operation to redraw the exposed portion. On a mobile device, this is burning CPU cycles (and therefore battery) for something that is just duplicating work. In contrast, with a compositing manager running the app only needs to redraw when something changes. The resulting window is stored as a texture. When you move one window, the GPU just composites them again. This takes a lot less battery power than redrawing. If the apps are drawing a lot of text, using XRender does all of the antialiasing on the GPU too, which reduces power consumption as well (rendering antialiased text on the CPU is insanely processor intensive, when you consider than text output was something computers were doing decades before the first GUI).
Sure, although even non-compositing WMs still offload most blitting ops to the GPU, due to the way Xorg accelerates operations. Also, if the Composite extension is present, you can do server-side compositing, which does the same snazzy window ordering without any effects or WM help.
In terms of power savings, it's not about saving CPU time as much as it is about GPU utilization, since the GPU will drink battery even when idling. The biggest battery gains we've been making aren't from extra GPU usage, but fro
FUCK THEM MAN FUCK THEM TO TEARS ALREADY !!!!!!!! (Score:5, Funny)
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 (Score:3, Interesting)
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 [android.com] 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. [androlib.com] What I am talking about are efforts by the search giant Google.
Re:This is for you RIM, Nokia, Microsoft and Apple (Score:5, Insightful)
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: (Score:2)
Nokia only intends to use Meego for N series, which is multimedia oriented, while the E series, aimed at business user (high end) still use Symbian.
Re:This is for you RIM, Nokia, Microsoft and Apple (Score:5, Informative)
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: (Score:2)
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.
Please provide a link to a place where I can download symbian sources, build them, and upload them to a phone before you say anything this ridiculous again. "Not all of the code is yet available [symbian.org] under open source licences". PURE FUD. STOP NOW.
Symbian also gives you many more choices for development than Android - there's a whole wealth of programming languages to choose from.
You can use all those languages on Android as well via the NDK, but if you want a GUI you will have to touch Java.
Re: (Score:1)
http://developer.symbian.org/main/source/license/index.php [symbian.org] says it's the tools code that currently isn't available, though I'm not sure what that specifically refers to. Also note from http://developer.symbian.org/wiki/index.php/Platform_Completeness [symbian.org] :
"However, some technologies which were historically included in Symbian OS / S60 platform releases were distributed under specific commercial licenses and hence could not be included in the initial Symbian Foundation codebase. Essentially Nokia have contribute
Re: (Score:2)
Essentially Nokia have contributed everything they can to the Symbian Foundation but some technologies are licensed from other companies and hence can't be included in the platform until discussions with those companies have been completed."
Yes, or in other words, portions of Symbian are closed and likely to remain so until Symbian is completely over. And since Symbian has been relegated to basement status (it will never be on another flagship phone made by any manufacturer anywhere anywhen) it is largely irrelevant anyway. The point remains that Android or perhaps MeeGo is the freest phone OS available, and Symbian is trailing well behind.
Re: (Score:2)
Now *that* sounds like fud to me.
Re: (Score:1)
Re: (Score:2)
Ok, I admit, I haven't tried.
> Please provide a link to a place where I can download symbian sources, build them,
> and upload them to a phone before you say anything this ridiculous again. "Not all
> of the code is yet available under open source licences". PURE FUD. STOP NOW.
However, I followed your link and one link deeper I find :
"Why haven't you made everything public?
Most of our code and tools code was originally contributed under the SFL. On 4th February 2010 we made all of our source code ope
Re: (Score:2)
With Apple you spin the acceptance wheel, with Google's vision of computing you will always have that doubt that one day your app might be gone.
The rest are what parents and grandparents are tied to by their profession.
What would be nice is a Linux desktop in your hand, free to code on and see the hardware, flip it over and you have a packet pushing networked phone. Linked by a data network you pay for, not legal teams
Re: (Score:2)
What would be nice is a Linux desktop in your hand, free to code on and see the hardware, flip it over and you have a packet pushing networked phone. Linked by a data network you pay for, not legal teams looking down at your mobile desktop.
Closed is great if you have to use it or get it for work, but we seem to have a real effort to trap developers in an almost free until you read the fine print walled gardens.
N900?
Re: (Score:2)
> Whats holding back Android is Googles ability to "Bezos" away any app they dont like.
> With Apple you spin the acceptance wheel, with Google's vision of computing you will always have that doubt that one day your app might be gone.
Apples have the same problem.
Unless the user is in control of the device, this is a problem across the board.
It's not unique to Google (or Amazon).
Re: (Score:2)
And don't forget Cyrket [cyrket.com].
W
Re: (Score:2)
heya,
Actually, another thing might be the general shonky level of hardware...lol...
And it's not "bad" publicity on battery life. It's a known problem. I assume here you mean the Nexus One, Google's flagship Android phone.
As are the issues with touchscreen going out of calibration, and the 3G reception issues.
And the Motorola Droid has had it's series of hardware issues/quirks.
I've gone through two Nexuses - first one had an issue with the camera failing. The second, the GPS radio seems to have failed. And H
Re: (Score:1)
I worked for Gameloft on IPhones all day and I know what I'm talking about
Brilliant move (Score:4, Insightful)
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.
Re: (Score:2)
Its not necessarily the way to go - sure its probably the best way, but since when has that ever been a factor in human endeavours.
Let the hardware companies that they can keep their binary-only drivers, but they'll be maintaining them themselves. If the ABI was stable, chances are they'd be perfectly happy with this too. Linux would get hardware accelerated drivers, you might have to download them yourself from the manufacturer website, but otherwise all would be goodness.
Current status is a bit of a stand
Re: (Score:2)
Command stream protocol? (Score:5, Informative)
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? (Score:4, Informative)
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... (Score:2, Informative)
In the case of the Snapdragon-powered Sprint Evo, HTC [htc.com] still hasn't released kernel source after a month of distributing the binary kernel. Despite the fact that GPLv2 [gnu.org] requires them to release the source along with the binary...
Correction (Score:2)
Dave not under "Red Hat mind-control" (Score:2)
Re: (Score:2)
In this case, we (RH) don't even really need to be that Good. (Of course, we are - the sun shines out of our ass, etc etc). But in this particular case, as Dave says, RH - corporately - doesn't really care. RH doesn't have a horse in the race, when it comes to graphics on cellphones, after all.
Plenty of people at RH - mostly those of us who are stuck with crappy graphics adapters in our laptops / cellphones... - care about the issue, but RH as a company doesn't really give a rat's ass.