[Nexus One Android Development] storm99999:
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.