Active Topics

 


Reply
Thread Tools
ScottishDuck's Avatar
Posts: 76 | Thanked: 87 times | Joined on Mar 2010 @ Scotland
#1
The Free Software Foundation has now determined that reverse-engineering the PowerVR Linux drivers in order to create a free software driver capable of 3D hardware acceleration is a high priority action item. With an increasing number of mobile devices running Linux bearing these PowerVR graphics chipsets, which currently require the use of binary blobs for graphics acceleration, is not acceptable and that action must be taken to create an open driver for this hardware.

Following a proposal last month of reverse-engineering the PowerVR SGX GPU to create a "free software OpenGL library", the Free Software Foundation has agreed this is a high priority project. "PowerVR is a popular 3D graphics engine found in phones, netbooks, and laptops, for which we currently have no free software driver capable of doing 3D graphics acceleration."

The Wiki page for this project outlines the goals as being to create a Gallium3D PowerVR driver called G3D-SGX, port the OpenGL 3.0 Mesa library to G3D-SGX (but no complete OpenGL 3.0 implementation is yet available for Mesa...), investigate compiling through LLVM (the Low-Level Virtual Machine) to take advantage of the multi-core SoC with the ARM Cortex A9 and other CPUs along with the vertex processing units and other co-processors on many of these SoCs.
http://www.phoronix.com/scan.php?pag...item&px=OTEwMA

FSF intend to rapidly develop an open/free PowerVR driver. This means all kinds of good stuff for maemo, it brings us much closer to a fully open phone and who knows, maybe we could start using newer kernels and other niceness in the future..
 

The Following 6 Users Say Thank You to ScottishDuck For This Useful Post:
Posts: 427 | Thanked: 160 times | Joined on Nov 2009
#2
what are their odds of success with reverse engineering? is it basically brute force and time until it works?
__________________
Please vote for the following bug:
Media player should play audio tracks continuously (gapless playback)
 
Posts: 100 | Thanked: 22 times | Joined on Jan 2010 @ San Diego, CA
#3
Perhaps someone with access to the actual drivers can "leak" it and pretend that it was reverse-engineered
 

The Following User Says Thank You to ktchiu For This Useful Post:
Posts: 2,802 | Thanked: 4,491 times | Joined on Nov 2007
#4
Look at the other items on the FSF's priority list and realise you're in for quite a long wait before something usable emerges, by which time the hardware you wanted to use it on will be obsolete.

ARM's Mali looks like a better long-term bet.
 

The Following 2 Users Say Thank You to lma For This Useful Post:
Posts: 842 | Thanked: 1,197 times | Joined on May 2010
#5
Ima, I would argue that it all comes down to a simple question: "Who cares about it?"
If the answer is "A few OSS advocates", nothing will happen. If it's "A bunch of users", not much will happen. But if the answer is "One or more kernel devs"(say, because they happen to have a N900 and want a driver to play some game)... It will probably happen in a matter of a month or two.

Thing is, of all the things on that list I don't see anything that would actually get some programmer to go work on it, unless he happens to really want it done - I mean, who -really- cares about a Google Earth replacement? Google's got a good API and it -works-, even on Linux!

On the other hand, if some dev wants to install Debian on his phone and decides he needs an open GPU driver... Amazing things can easily happen.
__________________
My projects: BackupMenu - OS Backup & restore | Video: Flashing your n900(LiveCD)
My devices: N770 + 8GB SD card soldered internally, N900 with 8GB SD card + Custom OC(125-950 typically).
OC freqs: 0:22,90 125:22,90 250:28,180 500:30,360 550:32,400 600:34,430 700:39,430 750:41,430 805:45,430 850:47,500 900:50,500 950:54,500 1000:58,500 1100:67,520 1150:71,520
 

The Following 3 Users Say Thank You to RobbieThe1st For This Useful Post:
Posts: 1,746 | Thanked: 2,100 times | Joined on Sep 2009
#6
Originally Posted by lma View Post
ARM's Mali looks like a better long-term bet.
Which is to say, sticking with the status quo:

For the r2p0 release we've opened up all the Linux kernel side components of the Mali drivers under the GPLv2.
And it's precisely that which is already available from Qualcomm, PowerVR, and Nvidia. Unsurprisingly, none of it has been accepted into the Linux kernel, and none of it gets you anything more than a software framebuffer unless you have a license to the driver source from the IP vendor.

The FSF is looking at the userspace, which is where all the valuable, useful bits like OpenGL ES 2 support is, and is no more likely to be opened by ARM than it is anyone else.
 

The Following 2 Users Say Thank You to wmarone For This Useful Post:
ScottishDuck's Avatar
Posts: 76 | Thanked: 87 times | Joined on Mar 2010 @ Scotland
#7
Originally Posted by jerryfreak View Post
what are their odds of success with reverse engineering? is it basically brute force and time until it works?
It's usually done by having people run opengl tests and seeing what the graphics chip does. It's not as difficult as you may think.

There is already quite a lot of groundwork in place for this driver. We might start seeing something usable in the next few months.
 
Posts: 1,680 | Thanked: 3,685 times | Joined on Jan 2011
#8
Remember abrahams dictum:

It is cheaper to reverse engineer than re-engineer.
__________________
N900: One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die.
 
Posts: 992 | Thanked: 738 times | Joined on Jun 2010 @ Low Earth Orbit
#9
Originally Posted by ktchiu View Post
Perhaps someone with access to the actual drivers can "leak" it and pretend that it was reverse-engineered
That is Microsoft's idea of "innovation". I hope the FOSS community would never stoop that low.
 
Posts: 2,102 | Thanked: 1,309 times | Joined on Sep 2006
#10
I guess it should be doable to sit in between the small and simple kernel module (which is not really the problem) and the rather large and complex user-space libraries, which are, and intercept the communications, mapping them to specific OpenGL calls. Would take time though.
 
Reply


 
Forum Jump


All times are GMT. The time now is 20:02.