Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,731,698 Members 48,766 Now Online
XDA Developers Android and Mobile Development Forum

[PROJ] Improve/Porting Adreno GPU drivers on Snapdragon Devices

Tip us?
 
babijoee
Old
(Last edited by babijoee; 22nd August 2010 at 09:35 AM.)
#1  
babijoee's Avatar
Retired Forum Moderator - OP
Thanks Meter 161
Posts: 1,525
Join Date: Dec 2008
Location: Melbourne

 
DONATE TO ME
Default [PROJ] Improve/Porting Adreno GPU drivers on Snapdragon Devices

Over at PROJ: Overclocking the Adreno GPU on Snapdragon Devices they were trying to achieve to overclock the GPU to improve performance.
I've decided to open this thread for dedication for software porting/improving for adreno GPU on all Snapdragon chips.

1st thing we require/need to start work is:
From there we should be able to improve our drivers from other devices but i think its a good start to look at the Acer Liquid since the source is available iirc.

That should be what we need for a start.
If i'm missing anything please let me know and i'll add it.

For reference to the other threads i posted.

Desire Porting thread | EVO4G porting thread | Incredible porting Thread


Hopefully we can get this project going and improve our GPU performance.


| TOUCHPRO | NEXUS ONE | DESIRE HD | GALAXY S III | GALAXY NEXUS | GALAXY S III 4G | SONY XPERIA Z |

The Following User Says Thank You to babijoee For This Useful Post: [ Click to Expand ]
 
babijoee
Old
(Last edited by babijoee; 1st August 2010 at 07:25 AM.)
#2  
babijoee's Avatar
Retired Forum Moderator - OP
Thanks Meter 161
Posts: 1,525
Join Date: Dec 2008
Location: Melbourne

 
DONATE TO ME
reserved for changelog


| TOUCHPRO | NEXUS ONE | DESIRE HD | GALAXY S III | GALAXY NEXUS | GALAXY S III 4G | SONY XPERIA Z |

The Following User Says Thank You to babijoee For This Useful Post: [ Click to Expand ]
 
babijoee
Old
#3  
babijoee's Avatar
Retired Forum Moderator - OP
Thanks Meter 161
Posts: 1,525
Join Date: Dec 2008
Location: Melbourne

 
DONATE TO ME
reserved for downloads/links


| TOUCHPRO | NEXUS ONE | DESIRE HD | GALAXY S III | GALAXY NEXUS | GALAXY S III 4G | SONY XPERIA Z |

 
storm99999
Old
(Last edited by storm99999; 2nd August 2010 at 03:49 PM.)
#4  
Senior Member
Thanks Meter 14
Posts: 365
Join Date: Nov 2007
Alright, I'm going to write out everything I know so far in the best of my knowledge to help with others who are looking at this project. Conjecture will be separated off as thoroughly as possible. Let me know if any of this is wrong or needs updating, it's to be informative as possible.

Acer Liquid E:

There is a kernel framework that activates the GPU and provides clock and power control. Changing these states seems to be interrupt driven, upon the right signal the clock will be shuffled through a few states depending on load. The clock is always set through the minimum clock rate and the maximum clock rate is inflexible.

Outside of this, there is a non kernel-level driver binary that controls all other GPU operations. We do not yet know where it is or how it operates in the boot process.

Known points of interest:
  • Liquid E roms, to find the GPU binary driver portion.
  • Kernel source/drivers/char/msm_kgsl for the kernel portion of the driver.*
  • kernel source/arch/arm/msm/
Nexus One:

There too is also a kernel framework. It does not appear to initialize the driver at any point. In fact, I cannot find any external calls to the kgsl code whatsoever. They are most likely called from the binary portion of the driver, whose whereabouts are also a mystery.

Known points of interest:
  • kernel source/drivers/video/msm/ and msm/kgsl
  • kernel source/arch/arm/msm/
Conjecture:

My personal belief is that the radio plays a role in the Nexus One's GPU control system. It is the only part I know of initialized early enough to get us a framebuffer that isn't the kernel. The GPU may still be initialized in some part of the kernel I have not charted, but I have yet to see anything. Those whom I've contacted on this issue have not responded.

On a related note, there could also be a security system in the radio (or even the GPU firmware itself) that prevents kernel access to specific functions and further prevents user access to specific functions. If it exists and if it's a problem, we may have to find a way to maneuver around it.

The Acer E's binary driver really should be in the main part of any packaged rom. Upgrading it would be too useful to lock off somewhere.

Questions to answer so far:
  • How does the GPU get initialized in both devices?
  • Where in the process does this happen?
  • What is done during this time? (control handed off, some lockdown event, clocks set, etc...)
  • Is there a security mechanism that is set differently on the Liquid E?
  • If so, can it be defeated?
  • Where is the binary part of the driver for both devices?
Expected gains

The Acer Liquid E benches ~50% better (in nenamark at least) than the Nexus One. If we can get their driver implemented on our devices, we should get similar gains in OpenGL ES 2.0. OGL 1.1 (and 2D if implemented differently) performance gains may differ.

Anyways, I'll try as best as I can to help out anyone who is trying this undertaking while at the same time trying to avoid riling up everyone as bad on the radio subject as I did in the other thread. Also, I'm running this all from memory, so everything may not be spot on.

* If needed, I can chart out the functions to create a pleasant flow chart for people new to this area to follow.

EDIT: Oi, there's something really wacky about my formatting, only certain parts actually look really bolded. It's like my fonts shrink slightly after the Acer Liquid E list. Hope no one has bad OCD like I do.

EDIT 2: Updated with Jack_R1's correction below.
 
rsm86
Old
#5  
Member
Thanks Meter 2
Posts: 52
Join Date: Apr 2010
nothing to add here but my support

best of luck gentlemen, I believe this is definitely needed.
 
tolis626
Old
#6  
tolis626's Avatar
Senior Member
Thanks Meter 617
Posts: 2,513
Join Date: Dec 2009
Location: Amaliada
About time such a thread got started!I was tracking the thread about overclocking closely,but things got a little too intense there...
So,because I was in the UK for vacation this past week(call me an idiot,I'll accept it) and just got back in Greece I have some questions.First,wasn't intersectraven working on a kernel with the E's driver built in?How is that going?And second,would it be of any benefit trying to port the driver bit by bit?I mean,we could port one "piece" of it at a time and see where in the process things get nasty.
Thanks!
 
Jack_R1
Old
(Last edited by Jack_R1; 2nd August 2010 at 10:30 AM.)
#7  
Senior Member
Thanks Meter 945
Posts: 4,300
Join Date: Aug 2009
Quote:
Originally Posted by storm99999 View Post
The Acer Liquid E benches ~50% better (in nenamark at least) than the Nexus One. The CPU on the E is clocked at 75% or so of the N1. There is a known relationship between the CPU and GPU clocks, so assuming it's perfectly linear, it is possible that the new GPU code would be 75% faster in OpenGL ES 2.0 code. Gains may be different in other OGL versions.
Have to correct this. The relationship of GPU clock to CPU isn't a given number, relationship to other places is. The GPU frequency is the same in Liquid E and in Nexus, so the gain will be 50%. Still, a lot to gain, if possible.
It's only semantics, but in case the porting succeeds - it's good to know the ballpark for the expected gains.
Best of luck with this effort, I hope it'll succeed.
 
storm99999
Old
#8  
Senior Member
Thanks Meter 14
Posts: 365
Join Date: Nov 2007
Quote:
Originally Posted by tolis626 View Post
And second,would it be of any benefit trying to port the driver bit by bit?I mean,we could port one "piece" of it at a time and see where in the process things get nasty.
Thanks!
We couldn't do it bit by bit, as it's an all or nothing deal, everything must be in place before the code works, but that did give me an interesting thought...

You see, iR did port the driver over, but it crashed on boot. There's two reasons for this, either it couldn't find a userspace driver and we're much closer than we think, or it went about the wrong way. We know that the driver can be ported without compilation errors based on this, so... I wonder if we can port both drivers at the same time? Give the framework for the current GPU driver to work so that it doesn't crash, but have the new driver reporting errors? It would at least show us a bit more about the boot process.

Say we had all of the new driver and all of the old. Only the new driver is "active" but the old driver has all of its symbols as they were. Any external program calling these symbols would get them, but they'd never be activated by the kernel. Even better, we could redirect the symbols to the CodeAurora equivalents. Then we could map what is actually called early on and possibly by whom.

It's a bit absurd, but it's a possibility going forward. Now if only we had some way of getting kernel panic dumps off of iR's kernel, then we could make some real progress.

Anyways, my big post updated to reflect Jack_R1's correction.
 
babijoee
Old
#9  
babijoee's Avatar
Retired Forum Moderator - OP
Thanks Meter 161
Posts: 1,525
Join Date: Dec 2008
Location: Melbourne

 
DONATE TO ME
Quote:
Originally Posted by storm99999 View Post
We couldn't do it bit by bit, as it's an all or nothing deal, everything must be in place before the code works, but that did give me an interesting thought...

You see, iR did port the driver over, but it crashed on boot. There's two reasons for this, either it couldn't find a userspace driver and we're much closer than we think, or it went about the wrong way. We know that the driver can be ported without compilation errors based on this, so... I wonder if we can port both drivers at the same time? Give the framework for the current GPU driver to work so that it doesn't crash, but have the new driver reporting errors? It would at least show us a bit more about the boot process.

Say we had all of the new driver and all of the old. Only the new driver is "active" but the old driver has all of its symbols as they were. Any external program calling these symbols would get them, but they'd never be activated by the kernel. Even better, we could redirect the symbols to the CodeAurora equivalents. Then we could map what is actually called early on and possibly by whom.

It's a bit absurd, but it's a possibility going forward. Now if only we had some way of getting kernel panic dumps off of iR's kernel, then we could make some real progress.

Anyways, my big post updated to reflect Jack_R1's correction.
This idea seems plausible, i'll pm iR if hes able to do that
If anyone reading this is also able to do this please let us know. I'm sure theres many people who are willing to test this.


| TOUCHPRO | NEXUS ONE | DESIRE HD | GALAXY S III | GALAXY NEXUS | GALAXY S III 4G | SONY XPERIA Z |

 
madman_cro
Old
#10  
madman_cro's Avatar
Senior Member
Thanks Meter 91
Posts: 981
Join Date: May 2009
i think that you should share this tread to desire and evo, and maybe get some more help from theirs devs. its basically what we all want
devices :
htc touch diamond 2- dead
htc desire- dead
galaxy s2 - sold
iphone 4s _lol - sold after 5 days
htc one x -dead. sucky phone
Samsung galaxy s4 i9505 - current

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes