• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

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

Search This thread

babijoee

Retired Forum Moderator
Dec 7, 2008
1,548
163
Melbourne
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. :D
 
Last edited:

storm99999

Senior Member
Nov 11, 2007
365
16
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.
 
Last edited:

tolis626

Senior Member
Dec 31, 2009
2,518
598
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

Senior Member
Aug 9, 2009
4,365
962
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.
 
Last edited:

storm99999

Senior Member
Nov 11, 2007
365
16
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

Retired Forum Moderator
Dec 7, 2008
1,548
163
Melbourne
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.
 

madman_cro

Senior Member
May 14, 2009
1,148
122
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
 

babijoee

Retired Forum Moderator
Dec 7, 2008
1,548
163
Melbourne
That's right.Evo,Desire,Incredible,they all use the same GPU.I too believe we could cooperate with devs from these forums.

Will do :) lets all work together


This brings back memories... :)

I'll keep an eye on this. Good job babijoee.

like you i want to improve graphics on our beloved devices.

Edit:
I've setup a duplicate thread in Desire,Incredible and Evo threads all linking back to this main one. Alot of people are thinking the way to improve GPU is only to OC it and NeoS2007 and myself know better. We both were involved in winmo msm7k gpu software/driver improvement and achieved great results with the help of other xda members/developers.
Not for one second did i believe that our devices were running optimised graphic drivers and other devices such as Acer liquid E for example proves that.
 
Last edited:

Geniusdog254

Retired Recognized Developer
Jan 2, 2009
1,110
169
St. Louis
Posted in the Evo section as well. Told some idiots to stay back :eek: :p

I think one thing that we had an issue with before was the fact that it wasn't integrated in the full Qualcomm kernel. There could have been other code in there it depended on that we didn't pull. We need to clone the whole CodeAurora kernel repo (.32) and build it and see if it boots.

Then there's the Liquid E stuff. And the new FroYo Sense kernel is a .32, so once we get HTC's source it may be able to be implemented there too. I don't think any of the Nexus kernels that are around are .32 so that could be why it wouldn't build.

Just my $.02
 

storm99999

Senior Member
Nov 11, 2007
365
16
<Postedit> I hope you guys don't mind me detailing out all of what I've done with hopes that someone will find it helpful, it's very... verbose. Plus, if I have to share the source, I can remember exactly what files were tweaked to send a smaller than 700Mb file.

Alright, here's my current plan once I get my build environment stable again (oh hey, Ubuntu 10.10? Do it!):

The N1 code has two layers, a wrapper layer and the interface layer. The Liquid E code has only an interface layer which appears compatible to (but different than) the wrapper layer on the N1. I'm going to replace the N1's interface layer to see if it still runs. If it does, we now will have a current kernel build that would allow both drivers to operate, barring complications.

The current driver would have all the wrapper layer code it needs, but the new driver will have the correct interface layer code it needs.

Then, I'll bust open a Liquid E rom (Aren't the Liquid and Liquid E roms interchangeable? That worries me.), hunt down the driver, find out how it starts up in the system, add it to a current rom, test it for differences, and then break the interface layer by putting no-op asm.

This is all simplified (and possibly horribly wrong) of course, but anyone looking at this project may be interested in trying something similar.

Edit: Alright, I found out that both of them have an on-boot frame buffer, but the new Qualcomm one is much larger and more capable. I'll start my porting project there, as that quite literally could be the difference.

Edit2: Oh god the Kconfig errors! They've overtaken the ramparts!

Edit3: It looks like I'm missing a large series of .h files, but other than that, there have been no compilation errors. Also, if you end up where I am, you want MDP31 instead of MDP40, kinda caught me off guard.

Edit4: I like keeping things written down for everyone. Anyways, here's the list of file movements I've done so far for anyone interested, as I need to make sure that if I get a result, it must be duplicatable.

Acer Kernel linux/include/msm_mdp.h must be moved to the same place in a Cyan kernel.
All of Acer Kernel's drivers/video/msm/ must be copied over but the kgsl folder must stay intact.
A blank Kconfig must be made in the same folder.
The Acer Kernel's drivers/video/Kconfig must be copied over. The options you want:
  • We have a MDP31 chip
  • Not sure yet, but autodetecting the panel is what I've chosen
  • MDDP 2.0 doesn't seem to matter, so best left disabled.


After all of this, there seems to be missing a single .h file, which has the function dma_cache_pre_ops() and related in it.

Edit5: I really hope that putting this much detail out doesn't bother anyone... Anyways, the next step fixed most of this, I modified msm_fb.c to have this in the definitions:

Code:
#define pgprot_noncached(prot) \
       __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_UNCACHED)
#define pgprot_writecombine(prot) \
       __pgprot_modify(prot, L_PTE_MT_MASK, L_PTE_MT_BUFFERABLE)
#define pgprot_device(prot) \
       __pgprot_modify(prot, L_PTE_MT_MASK|L_PTE_EXEC, L_PTE_MT_DEV_NONSHARED)
#define pgprot_writethroughcache(prot) \
       __pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITETHROUGH)
#define pgprot_writebackcache(prot) \
       __pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITEBACK)
#define pgprot_writebackwacache(prot) \
       __pgprot((pgprot_val(prot) & ~L_PTE_MT_MASK) | L_PTE_MT_WRITEALLOC)

This does throw some errors cause this isn't supposed to be there, but this is just a temporary hack.

The dma problem disappeared after that (don't know why...) and now I just have to find out why "info" is undefined at line 840 now.

Edit6: It looks like disabling the boot logo (as dumb as that is) gets rid of that error, but it throws a warning that the system needs the logo to be enabled. It's just a temporary measure, plus, I'd love to see a logo-less boot screen.

Edit7: Added a NULL to line 104 in drivers/video/msm/msm_fb_bl.c before

Posted in the Evo section as well. Told some idiots to stay back :eek: :p

I think one thing that we had an issue with before was the fact that it wasn't integrated in the full Qualcomm kernel. There could have been other code in there it depended on that we didn't pull. We need to clone the whole CodeAurora kernel repo (.32) and build it and see if it boots.

Then there's the Liquid E stuff. And the new FroYo Sense kernel is a .32, so once we get HTC's source it may be able to be implemented there too. I don't think any of the Nexus kernels that are around are .32 so that could be why it wouldn't build.

Just my $.02

I have been using http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/staging/msm/mdp.c as a base reference for my work and for bugfixes, as the staging area has the driver implemented as a .35. I'm going to try something, maybe downloading the whole source from this one repo and using the config I got, maybe it will spare me the issue. It's so clean, so error free, I'm liking it.

Edit9: Alright, downloaded 2.6.35 kernel, copy-pasted staging driver, got rid of all the errors prior.
 
Last edited:

storm99999

Senior Member
Nov 11, 2007
365
16
Wow great start storm :) it sound like you achieved quite alot in write short time frame. Keep it up. Need any testing? Let any of us know :p

Oi... I'm far away from testing here, my current goal is just to switch framebuffers... I realized where I'm going wrong, so I'm rebasing to iR's kernel source. It's a .35 source and that's been where all of my problems have been.

Quite literally, here's my procedure as of now: Get the Kconfig for drivers/video from the Acer Liquid E driver, copy and paste the framebuffer code from drivers/staging/msm to drivers/video/msm, try to compile.

I'll keep this post updated once I get the iR source downloaded.

Edit1: Alright, got my compiling to work, so far the only tweak I need to do is add "#include <linux/android_pmem.h>" to msm_fb.c (edit3: instead, put in msm_fb.h) , still having errors in GPIO...

Edit2: Added definition list from mach/proc_comm.h to staging-devices.c and mdp_vsync.c, repeated adding NULL as above in edit7.

Edit4: Changed line 23 in mdp_ppp.c to #include "msm_mdp.h"

Edit5: Commented out line 71 and 72 in mddi.c

Edit6: replaced dma_coherent_pre_ops and post_ops with dmb, as the functions prior don't exist and a commit says dmb replaces them. Really not sure about this. Compiling is smooth sailing from hereon out, except a duplicated function. Let's see if it kills my phone. :p
 
Last edited:

jakeneal22

Senior Member
Jul 12, 2010
404
37
I have read through this and can say I honestly have no idea what half of the mumbo jumbo means but ill give it a bump and good luck to all you devs.

Sent from my Nexus One using XDA App
 

babijoee

Retired Forum Moderator
Dec 7, 2008
1,548
163
Melbourne
Oi... I'm far away from testing here, my current goal is just to switch framebuffers... I realized where I'm going wrong, so I'm rebasing to iR's kernel source. It's a .35 source and that's been where all of my problems have been.

Quite literally, here's my procedure as of now: Get the Kconfig for drivers/video from the Acer Liquid E driver, copy and paste the framebuffer code from drivers/staging/msm to drivers/video/msm, try to compile.

I'll keep this post updated once I get the iR source downloaded.

Edit1: Alright, got my compiling to work, so far the only tweak I need to do is add "#include <linux/android_pmem.h>" to msm_fb.c (edit3: instead, put in msm_fb.h) , still having errors in GPIO...

Edit2: Added definition list from mach/proc_comm.h to staging-devices.c and mdp_vsync.c, repeated adding NULL as above in edit7.

Edit4: Changed line 23 in mdp_ppp.c to #include "msm_mdp.h"

Edit5: Commented out line 71 and 72 in mddi.c

Ah k :) thanks for the update.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    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. :D
    1
    reserved for changelog
    1
    We'll see with the gingerbeard drivers.

    I get usually more then 10% boost in nenamark, bit more, something between 15-20% boost.

    Also in games, it's VERY easy to notice the extreme smoothness, people, it's totally going much higher then the 60 FPS limited by the frequency of the display. We should try this thing I suggested earlier:
    http://forum.xda-developers.com/showthread.php?t=755671

    Y'know, although texture resolution changes would be cool, wouldn't it be more universal and effective if we tried to change how a game rendered itself? On PCs, I know this is driver level stuff and we don't have much driver level control, but say we mapped, in pseudocode of course, RenderWithoutAA to RenderWithAA and force antialiasing on games.
    1
    Okay so playing Brothers in arms 2 I realised a really big problem with adreno that's been here for a while: Any particle or transparent texture result in HUGE FPS dropdown, so i think this is No.1 on the list now.

    Anyone knows a book about glES 2.0? Thanks.

    So, adrenos struggle with transparent billboarding, or is it something else? As for the book, if you find one, let me know. I've been wanting to get into this for months.
    1
    The answer is easy:
    No, I don't have money and I can't buy any of these books, the material on the internet is either outdated or misleading, and since I have no material to work with...

    We wait for Nexus S to be released, when it's released the AOSP(source code) will be out, and then I/we can work on this.


    But something I have found is that it's really easy to convert glES2.0 to glES1.1 - and that would be a huge performance boost in games like asphalt or brothers in arms 2. Though I think forbidding to render transparent textures would be more effective and easier to do.

    edit:
    oh yeah the AOSP is out! But I don't have enough HDD space to compile it =/