yashsingh1/xdaforums huggingface dataset:
[HTC One X] neuTrue:
@Kholk :

We agree it's the memory fault here, however our suggested solution was meant as a way to fix it. Also, I can see from your perspective, how you concluded it wont work/not significant to overclock AHB for GPU. However, the problem arises here, that we don't have enough data to support either of our claims. At lest, no data for Tegra 3, but there are PC data that we can use.

Thankfully, someone already compared some data and concluded the results, in which it could support AHB overclocking.

Now, does this mean that any serious work should be done ? The answer is definitely not, well not at this stage. We only need a proof of concept.

So, I suggested to have two kernels: One with AHB overclocked ,and one without (no interface, nothing, the easy hackish way), and of course both of them should have GPU-OC interface. After that, we need to search for a friendly and kind person to give this a try (@Hamdir :P).

About, GeForce ULP-24bit, I have never though about it (one word: genius! + for other things as well).

Speaking about GPU's vs CPU's, it is only 2.5X the performance (approximately in PC, with i7). ARM still no match for X86_64 (real 64bit vs 32bit arch) and adding to the mess Tegra 3 GPU, I'd say the answer (to Q3) is nearly 2 seconds.

6- Only with Chainfire3D (a possibility).

Regarding, the resolution and restarting the driver. Before, you do that, can we have a proof of concept first? This will determine, if it is really worth it or not. As usual, we need someones who's friendly enough to do the benchmarks (@Hamdir :P).

To summarize this post:

We need the following proof of concept kernels (hackish way):

Moderately overclocked AHB kernel (you pick the AHB frequency).

Hard-coded kernel with (960x540 and 1024x567) resolutions.

16bit GPU kernel.

By the way, thanks for your useful post! :)

About why on 16bit, we don't notice much visual imperfection (SGS3 example), my answer would go for dithering.

Side note:

If Hamdir is going to start a donation campaign, include me in.

Also, I'd like to suggest that you release a multi-donation app or anything like that on Android Market, ($1,$1,$1,$2,$2,$2,.....$25), would helps many people to donate (me included).
[HTC One X] kholk:
I like your spirit!

We haven't got any number in our hands, heh, that's true, but don't undervalue what I said about AHB frequency and side effects of insufficient bandwidth conditions ;)

Then, please, don't take PC GPUs as an example... on the x86/x86_64 world it works differently: just think that on there you've got many parameters to check, such as PCI-Express' frequency (and available bandwidth), southbridge, northbridge, HTT(if AMD), blahblahblahblah etc :P

Also remember that x86(_64) systems are built on compatibility: your mainboard (just an example) can use a Radeon HD7770, a GeForce GTX690 or an old model or a dual-GPU model. Those cards needs different bandwidth, so they're just giving you the "most compatible" thing (that bandwidth that is being used by the GFX is being shared with lots of other components and frequencies have to be calibrated for ensuring system's stability).

On our ARM system, the GPU is integrated into the SoC itself and there aren't so many dedicated busses: it's really a lot simpler thing, also because the chip manufacturer doesn't have to make any "generic" calibration, but only chip-specific!

Getting back to the practical discussion:

It's possible for me to build those three proof-of-concept kernels.

Just making my work to be lighter, it's okay, I'll try to make the three modifications in a really, _really, really hackish way, just for you to get benchmark results, so if there'll be any glitches I won't spend lots of time to find a fix.

Glitches won't invalidate benchmarks results.

Once chosen the best way, I'll make something decent for the public version.

I think you're okay with that.

About the donation app, yeah, okay! I'll tell lowjoel to do that (he's the app developer!) and thanks for the idea! :D
[HTC One X] hamdir:
@neuTrue, i really think interface OC or Resolution trick are the harder ways

if we manage to pull out a 16bit hack, i think it might be all we need

@kholk

BRING IT ON! my PM is clean an empty for the betas :laugh:

PS: any comments about the wall charging bug?
[HTC One X] kholk:
The resolution trick is the hardest one, sincerely. We need the panel's datasheet for it and it's not available.

I've been able to configure some panel parameters in the past using electronics equipment for examining the signals, but the parameters required for full-screen and less-resolution can be found only on the datasheet.

Those can't be "calculated".

BTW, I have to correct myself. We aren't running at 24bits but at 32. (LOL)

About that wall charging bug... ehm... what? :P

I'm not experiencing any problem!

EDIT:

Actually tested (ready) both resolution hack and bits hack. As soon as I'll get a working AHB OC I'll post a package here containing the kernels.
[HTC One X] timlambo:
How I long to use your kernel again. Just wish HTC can finalise their jb Rom and release kernel source. Do you maybe know how to(if possible) to use such a kernel with jb?
[HTC One X] Thunder07:
Sweet, so How low are you going 24 or 16bits?

Sent from my HTC One X
[HTC One X] kholk:
@timlambo

Just use the new ramdisk by hTC, at least from what some users are saying :)

@thunder07

It depends from lots of things. I don't know what to say in this moment sincerely!

Let me examinate the situation and you'll have something to read :P
[HTC One X] batna.antab:
32bit on a smartphone LoL.

About the charging problem I was experiencing that too but after like a week it disappeared.

You haven't still responded to my question about the issue on your website, the download for the cm10 version downloads the older version(0.99) instead of the 0.99b but the modules are right.
[HTC One X] kholk:
Well, the images are ready.

The package contains 5 kernels:

- 960x540 hardcoded (bad touchscreen calibration, only a portion of display working)

- 16bpp (crazy transparencies, ehm.. but still "usable")

- 16bpp with AHB and APB overclock (same)

- 24bpp with AHB and APB overclock (looks like perfect!)

The kernels are 3.5, not 3.4, so if you want to test, flash a 3.5 kernel with his modules prior booting one of those images.

Those images are only the kernel, without any ramdisk, so for booting it, reboot to bootloader, then...

fastboot boot (name)

Like that you'll be able to boot only the kernel without flashing it (reboot will boot to the currently flashed kernel).

I've compiled this on the 3.5 base and without including ramdisk for praticity (for me, because I'm using 3.5).. and it isn't a boot.img with ramdisk for the same reason.

Just make sure you've flashed my 3.5 kernel with its modules and that it boots prior "fastboot boot kernelname".

Let me know your results :)

Ah, get it HERE

@batna.antab

Going to fix it instantly.
[HTC One X] hamdir:
kholk I'm speechless I'm outside town for the day, believe me if I knew it will be this soon I would have stayed home

the moment I arrive home tonight ill be doing extensive gaming and gpu benchmarks

do you really mean 32bit 3D rendering ? or global? ofcourse the OS will need to run in 32bits for image quality reasons otherwise everything will look bad, I thought we are talking about a 3d mode hack

if indeed 3d is rendering in such precision NV must be out of their mind

can I use this on my sense 2.17 rom?

finally yes whenever I flash ur kernel repacked on my stock 2.17 Rom my phone fails to charge using the wall charger 50% of the times, with or without charger boost, dunno if I let it settle like batna said, ill try
[HTC One X] kholk:
Yup you can use it on Sense, no problem (most probably).

About the 32bits, it's global.......

....and yeah, it's crazy. The max we should use is 24bits!

All of the non-Tegra3 Android devices are running at 16 or 24 bits and the majority is running at 16bits.

Are you convinced now of how much powerful GeForce ULP is? :)
[HTC One X] hamdir:
one more thing I think we will need a pure stock 32 + APB AHB OC in order to test purely the OC benefits

edit: I saw ur response yes I'm surprised, 16 is too little 24 should be the sweet spot, but I'm sure its for gradation concerns since apple is 32

can we change it on the fly? (in the future)
[HTC One X] kholk:
uhm.... are you sure that Apple uses 32bits? Usually 24 is enough for the human eye.

We'll be able to change it on the fly, most probably, anyway.
[HTC One X] hamdir:
yes the OS is definitely 32 dunno if the 3d is rendering in 32 too

look the Mali400, 16 trick is surely in the 3d only? can't imagine the OS is 16 as well!

anyway as long as its a switchable we can keep it off by default easily n call it before gameplay using gaming boost or scripts
[HTC One X] Thunder07:
well, i've just tested both 16bpp & 24bpp and im getting similar quadrant scores :/

i know benchmarks arent the best... but surely there should have been a difference is 3D scores??
[HTC One X] timlambo:
You should use GL benchmark, espescially for 3d.
[HTC One X] Thunder07:
i keep getting invalid package :/

ill have another go at installing it
[HTC One X] hamdir:
gl benchmark is the only accurate gpu test

test Egypt HD onscreen
[HTC One X] kholk:
The Mali400 runs at 16bits . and for "." I mean "full stop". :P

Everything runs at 16bits on Mali400.

@thunder07

Thumbs up for GLBenchmark! :)
[HTC One X] hamdir:
let's hope it will give us what we expect

not even anandtech noticed this in their tech analysis

can I ask for AHB OC with 32 image and 24 bit without AHB oc image? it will help me test the exact benefits from bitrate change
[HTC One X] timlambo:
Having no luck with repacking what so ever. Back to stock. :(
[HTC One X] neuTrue:
@Kholk :

Thanks for replying & even more thanks for your 2nd post (and the rest)!

I slept for 2 hours and many things happened, seems like I slept 2 days ,either that or Kholk's work & time is measured by speed of light! ;)

I'll try to be short, here. I though that AMBA specification was set, to be more like buses with full control (in all of it's variates) in PC hardwares. The worst part of overclocking AHB (in my opinion), would have been with un-synced components working together.

About the donation apps, scratch that idea. Now, that I slept I have a clear mind. It will get your app list crowded in Android Market (under Eternity Project name). Imagine, there are like 50 apps with different value and all are the same, and among them you only have 2 useful Eternity Project apps, this mean the 2 different apps will be hidden. My best suggestion is to have a one donation app ,and inside that app, it should include in-app purchases (IAP) with many options ($1,$1,$1,$2,$2,$2,....$25).

@Kholk's 2nd post:

LOL, 32bit!!! The more, the better results we get from lowering it! :)

If you know the panels name & model, tell me what it is ,and I'll try to get it's datasheet.

@Khok's 3rd post:

Now that's crazy! 5 different kernels in less than 24 hours!

@Thunder07:

Don't keep us waiting for your benchmark (I'll be refreshing Glbenchmark page = faster :P).

About benchmarking, I would have done it myself, but still haven't unlocked my bootloader ,yet (LOL + facepalm).

[Edit]

@Thunder07 :I can see your results starts to appear on GLbenchmark, just a reminder. Don't forget to force GPU OC-ing. :)

[/Edit]

//I'm already on my thanks limit, I'll thank you all when the limit is lifted.
[HTC One X] Thunder07:
ill be doing 3 tests,

1. Control with gaming kernel (done)

2. 24bpp kernel

3. 16bpp kernel

so it might take a while :p

ok... what are the cmd for GPUOC??
[HTC One X] neuTrue:
Here you go, https://play.google.com/store/apps/details?id=eu.eternityproject.eternitytweak (the easy way).

By the way, I am more of waiting for resolution/AHB benchmarks. But, I'll be waiting for your tests as well. :)
[HTC One X] Thunder07:
ill leave the resolution one until the end,

now these are the results and from what i can tell, gaming isnt affected at all,

maybe because games use a different bit from the OS thus we need to find that??

these test are without GPUOC

ill run GPUOC and post the results...

EDIT:

GPU is at 520 already
[HTC One X] neuTrue:
@Thunder007:

"GPU is at 520 already".

There might be a problem with hardcoded values (I hope so!), the same happened with GPU overclocking, until the problem was discovered.

You could try the overclocked buses & resolution kernel now. :P

In theory and what most of us expect: We should get higher FPS with overclocked memory + overclocking GPU (if I remember correctly, there was no real gain @600mhz, and now we should see an improvement).
[HTC One X] Thunder07:
its a pain navigating with lower resolution but i just played a game of NFS with N7 patch,

i played a level with 2 road blocks at the same point.............................. guess what... it didnt lag one bit :D

now ill see if i can run any benches :)

BTW all my test where done with the AHB and APB overclocked kernels...

are you saying i should overclock with 600mhz???

jump to the IRC its easier to chat there.

Edit:

@kholk

it'll be great if you can scale up the lower resolution, it will make navigation so much easier,

ya we are benefiting with a lower resolution as the GPU fill rate can keep up with the res, that's why NFS didnt lag :)
[HTC One X] neuTrue:
Now that explains why your Glbenchmark results stopped from appearing. :P

Did you try it without N7 batch? With the 1500mhz mode. It is normal that you can't navigate easily, the touch screen isn't calibrated (I mentioned that it will need to be done, I think I said couple of days ago in Hamdir's mega thread).

The most important question, did the quality degrade so much at the lower resolution?

Also, sorry for not being clear about AHB overclocking.

In past, Hamdir tried to see how did overclocking GPU affects the FPS performance in Glbenchmark and gaming in general.

He tried to raise GPU frequency ,until he was not gaining much from the overclocking. That's how he confirmed, Tegra 3 GPU should be set at 520mhz as there was no real gain from overclocking it more than this.

Imagine these arbitrary values for GPU OCing:

@100mhz

, you get

10.0FPS

@150mhz

, you get

15.0FPS

@200mhz

, you get

20.0FPS

@250mhz

, you get

21.0FPS

@300mhz

, you get

21.7FPS

​

From these values, you will end up realizing the best overclocking value is around 200mhz, and after that some sort of bottlenecking happened.

With AHB/APB overclocked, we hoping to get more like @250mhz, 24FPS (from the arbitrary values).

I wasn't suggesting you to overclock your GPU to 600mhz, the risks of overclocking applies here. If you only want to do it, then do it. :)

Edit:

About the IRC, I'd rather not using it (left it for more than 7~8 years ago).
[HTC One X] hamdir:
yes I won't be able to join the party before few more hours

thunder keep in mind NFS is already super smooth on the work kernel :) unlike most other kernels :D so yes resolution scale will definitely speed things but try something heavier

I was a little skeptic to be honest about the bits, 3d render precision is totally different to OS precision I don't think its the sane value, unless are you seeing graphical issue with 16 bit in games?

finally for the memory interface to show its goods u need to OC gpu a bit more
[HTC One X] Thunder07:
the problem with navigation is, that the resolution lowered without scaling up (making visual comparsion impossible),

that way we had black bars at the side of the screen and the touch was still spread across the whole screen

i dont think i have hamdir patience to go through them like this :p

and i'm going out in a bit, so full effect NFS will be my last test, not to worry,

once we have hamdir he'll get to proper testing :D

i know but thats the only game i have,

long story short, the phone should have been sent to repairs a month ago, so much so im running full stock :p

i dont recall any difference running 16bit vs 32bits in games :/

ill give it a go in a sec

Edit:

ok so the game runs so smooth (lower res + full effects) when you get to a road block it does slow down... but stays very smooth and consistent

im guessing this also applies to the N7 patch but as it was soo soo smooth i missed it :)

Edit2:

ok.... so i can confirm (i think)

that the 16bpp does apply to the game itself(3D) but it does apply to its menu

which means there is another value somewhere for gaming/3D bits

thats why the difference in GL benchmark is negligible

this is how the phone looks with low res,

and non of the key button work
[HTC One X] hamdir:
ok I'm heading home

just a question will the modules from eprj v0.99b work?
[HTC One X] Thunder07:
Ummmm..... Dunno, don't think so, kholk said this is based 3.5 so I used his 3.5 kernel modules.

Also with decreased resolution we should be able to increase screen refresh rate.

Sent from my HTC One X
[HTC One X] hamdir:
where? where can we find 3.5 modules im confused? i can find them anywhere
[HTC One X] batna.antab:
He has a thread here in xda for the 3.5 kernel.
[HTC One X] Thunder07:
[KERNEL][USBHOST][29/10] EternityProject Kernel 3.5.0 v0.10 | EXPERIMENTAL

Direct Link
[HTC One X] hamdir:
i couldnt find it on xda

but i found it on his site

kholk always full of surprises :)
[HTC One X] joewong1991:
Bookmarked

sent from my renovated gaming beast
[HTC One X] hamdir:
before we start guys i tested the 3.4 kernel on its own

you have to know unlike any other kernel, this kernel runs NFSMW extremely smooth, almost locked 60fps, with very little lag on police blocks

yea so who ever tests has to keep this in mind, i know we all want hacks to make the One X run games better but the fact is, this kernel is already a very impressive boost to gaming :laugh:

On thing though im a little disappointed kholk moved to 3.5 before killing all the bugs on 3.5, if i have a fixed 3.4 with sweep2wake, no wakeup delay and fixed wallcharging i might very well not flash the JB update when it arrive, the gaming on this kernel is this good already!

beginning tests....
[HTC One X] hamdir:
Ok here is my report, test on stock 2.17 ROM:

Conclusion 1: 16bpp is working on 2D but not 3D, graphics corruption is evident on UI and games menu, but gameplay remains the exact same with no graphics artifacts, benchmarks and game tests revealed zero performance gains, this must mean the 3d mode precision is separate from the global and hence 16bpp is not working for ingame

Conclusion 2: AHB and APB overclock is not working or not doing anything, no performance or benchmark gains

Conclusion 3: GPU OC interface isn't really working, while GL benchmarks results are inline with GPU520 OC (36 egypt offscreen), changing the GPU values using Eternity tweak didn't stick, manual echo did change the parameter values but results in test revealed no gains, 600mhz should achieve 38fps egypt offscreen but its not, hence GPU OC interface isn't really working and i couldn't tests benefits of AHB OC + GPU OC

Finally

960x540 mode i was not able to get past the HTC sense lockscreen :) ill keep trying but form thunder07 results we do see gains in the GL bench test and ofcourse actually gaming gains are definite in such reduction but the question is how to run it ondermand and ofcourse scale it up?
[HTC One X] Thunder07:
hehe i probably should have mentioned how i've got past it :D

ummm...

lower the notifcation bar, open settings,

connect the phone to the pc and through adb shell, kill settings, something like "adb shell pkill com.android.settings"

and vola..

if you happen to open an app which doesnt have a close button,

just "adb shell ps" look for its name, "adb shell pkill name"

i should hit the sack now, good night all
[HTC One X] hamdir:
thanks thunder for the tips :good:

so i just finished testing the 960x540 image

and it just shows T3 should have been aimed for QHD devices and not HD

NFSMW is super fast in 1300 mode and very playable in 1500 with motion blur, even with fast cars, road blocks has a tiny bit of lag but this is not T3 to blame, it seems a game bug failing to cull them for the T3 GPU

Beach buggy full smooth at full graphics slider

wildblood 1.0.7 playable in full 1.0.7 graphics, yes playable but not super fast either

Egypt HD onscreen jumped from 15fps to 18fps (its a considerable jump for such a heavy test)

which shows a resolution trick is still the quickest way to quickly gain fps in games but we will need to have it scale up and ondemand (i know its hard or impossible)

16bpp, 24bpp tricks are not working ingame simply changing in 2D but not 3D, which means they are separate, which is also a good news, if we can only change it in 3D while keeping 32bit for 2D and UI it would be great, however it might also need 3d is already 16bit ;)

AHB OC seems to do nothing

GPU gpu_frequencies parameter are not doing anything either, it stuck at 520 no matter what you change

@kholk the ball in your park now :)

- make sure AHB OC is really working

- make sure gpu_frequencies interface is really working (you can check using GL bench)

- 16bpp/24bpp in 3d mode or T3 is already rendering 3D in 16bit?

- scaling in 960x540 mode?
[HTC One X] kholk:
AHB and APB OC _are_ currently working. I told you that it wouldn't make any difference and now you've seen it with your eyes! :P

The GPU freqs sysfs interface is working... perhaps there's something with EternityTweak: I'll tell that to lowjoel.

3D shouldn't be _already_ rendering at 16bits.... what I changed is the global bpp, but perhaps, there's another setting somewhere for 3D only.

It's unlikely, but maybe there is.

Scaling.... it's the most difficult thing in this world, you know?

Unless there are ways I'm not aware of, we need the panels datasheets :|
[HTC One X] batna.antab:
One X plus kernel source seems to be online, will it be useful?
[HTC One X] hamdir:
yes its good that we know about AHB OC, i think we should drop this idea because the device was very hot during my tests

and like you said Res and scaling is hard, so this leaves 16bit in 3D :D

did you check these?

/sys/devices/tegradc.0/graphics/fb0/bits_per_pixel

/sys/devices/tegradc.1/graphics/fb1/bits_per_pixel

by the way on the stock kernel i can change them both, when i change the fb0 one the display glitches for a split second

on your kernel i can change just the fb0 and it also glitches, so far i didnt really notice change ingame but will run some benchs to confirm

one more thing

there is a serious wall charger problem with the 3.4 kernel mate, 1 out 5 tries for the charger to work, ie: it either shows as charging but simply hold at the same power level, or actually charges the better, i really hope you can look into it
[HTC One X] neuTrue:
Thanks for your efforts, and sorry for annoying you about it. :)

However, this is really giving me a hard time. :\ How could it be that changing a bus speed doesn't have an effect on the system! It just doesn't make sense to me! Unless you overclocked the buses by +1mhz (I doubt it :P). Two hours of thinking, and I decided to relief my brain, and conclude AHB/APB overclock didn't work (logical conclusion). :S

If it is possible, can you give us the name/model of the panel?

We all going to try to find the datasheets (and hopefully, we find it). :)

I don't think it going to be a help in resolution/16bit matter, but due to similarities with One X (Tegra 3), I am sure Kholk can find something useful there.

Are you sure the heat isn't normal? I know overclocking buses should results in consuming more current ,and that's mean more heat. If that's true, then it worked. Still, I can't figure out how it didn't have any impact on the 3D/CPU benchmarks (Glbenchmark/Quadrant)!

Edit:

@Kholk:

Can you take a look into this (at least, before you release v1.0)?

http://kerneldedup.org/en/projects/uksm/
[HTC One X] hamdir:
yes its all very confusing but it was hot that much i can confirm

the 16bit situation is even more confusing...