Slashdot Mirror
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."
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.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
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.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
What is it with these ME-TOO asswipe corporations that show the tits but keep the pussy behind a chastity belt?
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.
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..."
~ C.
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.
Weaselmancer
rediculous.
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!
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...
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.
Qualcom have released "some" open source 3D driver code, yes folks there is a lot of code missing or obfuscated by proprietary libs . The qualcom snapdragon cpu isnt much better either. After the FOSS community having to deal with Qualcoms shenanigans I can understand why Apple bought it's own arm design house and is now getting samsung to fab a CPU for the iPhone and iPAD called the A4. Why put up with all the qualcom crap that android devs/device makers are putting up with when you can stick your middle finger up and make your own CPU. There is an upside though, Intel is porting Android to X86 so we may get some nice Atom cpu tablets on the market soon without all the stupidity that qualcom and its lawyers are introducing.
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.
"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).
I am TheRaven on Soylent News
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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?
~ C.
"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 from getting the GPUs to turn down so they aren't always running full-tilt.
~ C.
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 on scroll, it does it more if I have more windows open (more memory used?) and it still trashes if RenderAccel is disabled. This experience has actually put me off of AMD somewhat, because not only can I not use the graphics reliably under Linux in spite of the GPU core being an antique, but AMD didn't bother to contribute power saving feature support for the Linux kernel. Consequently my "netbook" (subnotebook really) which gets 5 hours under Windows gets about 2.5 under Linux. That's not ATI's fault though, except that AMD and ATI are now one company. The system also crashes on suspend under Windows 7, but it does that on Linux, too. This is clearly a video driver problem (at least on Windows) because it doesn't happen on the VGA driver. This CPU (Athlon L110) and chipset were both brought to the market in consumer devices after the announcement of Windows 7, but AMD never bothered to release any Windows 7 driver downloads for it (until recently, when an outdated video driver showed up) so it's still ticking along on old drivers... but not well.
Every time I've bought and AMD card I've suffered. Every time I've tried to use Linux with ATI graphics I've suffered even more. nVidia may be a bunch of bastards, but their cards work, so long as you don't buy the latest and greatest and try to use it with Linux. That's even more of a recipe for disaster with ATI, however.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Dave Airlie denies being under Red Hat mind-control in http://lists.freedesktop.org/archives/dri-devel/2010-July/001855.html It's good to see that the Red Hat drones working on the kernel are allowed (or atleast claim) to be kernel developers first and corporate slaves second.
9/11: Never forget it was a false-flag operation