54 replies to this topic

[tedkord]

xlightwaverx, on Mar 10 2011, 15:16, said:

Ok, I just did some thinking.  I believe the results of the BoosterCab will depend on how much of a PP your current ROM has.  I may be opening up too much throttle for a low PP ROMs, and in turn, it will bog the system down.  Please report PP with results so that I may adjust.  I may even do separate releases for each PP listed.  

X

What PP size do you have in your ROM? I think AMD's ZeroSense come with a 16mb pool, but I dropped it to 12mb (or 12mb down to 8mb). AMD, if you're reading this, what's the PP size in your newest Ultralight+sense?

[amdzero]

tedkord, on Mar 10 2011, 22:45, said:

What PP size do you have in your ROM? I think AMD's ZeroSense come with a 16mb pool, but I dropped it to 12mb (or 12mb down to 8mb). AMD, if you're reading this, what's the PP size in your newest Ultralight+sense?

12MB PP for ultralite and ultralite+sense.

[xlightwaverx]

amdzero, on Mar 10 2011, 21:48, said:

12MB PP for ultralite and ultralite+sense.

Same here, 12PP.  Not sure why it is bogging his phone down.

In my research, I have read where changes in these registry settings are only relevant in the boot.rgu file, and remain useless if changed within the system registry.  Is there something done with the boot.rgu that is different than the other registry information that gets added in?  I see drastic changes when I alter these settings, especially glyph*.

Any information would be greatly appreciated.

X

Edited by xlightwaverx, 11 March 2011 - 03:35 AM.

[amdzero]

xlightwaverx, on Mar 10 2011, 23:32, said:

Same here, 12PP.  Not sure why it is bogging his phone down.

In my research, I have read where changes in these registry settings are only relevant in the boot.rgu file, and remain useless if changed within the system registry.  Is there something done with the boot.rgu that is different than the other registry information that gets added in?  I see drastic changes when I alter these settings, especially glyph*.

Any information would be greatly appreciated.

X

Not to my knowledge.  I messed with the glyph caches before back when ZeroSense was DC23, but I didn't see a difference so I stopped cooking them in.  AFAIK all the .rgu files (except boot.rgu) are merged and put into two files: Default.hv and User.hv

Boot.hv is separate.  Try cooking these settings in and see.

[tedkord]

xlightwaverx, on Mar 10 2011, 22:32, said:

Same here, 12PP.  Not sure why it is bogging his phone down.

In my research, I have read where changes in these registry settings are only relevant in the boot.rgu file, and remain useless if changed within the system registry.  Is there something done with the boot.rgu that is different than the other registry information that gets added in?  I see drastic changes when I alter these settings, especially glyph*.

Any information would be greatly appreciated.

X

Hey, X. I downloaded your latest v.2.0 ROM last night and loaded it into Wes's ROM tool, and it reports 16mb PP, not 12. I think I was at 8mb, 12 at most. I'm going to flash each of your's and AMD's latest and try this patch when I get the time. I also D/L'ed AMD's Ultralight+Sense test 4, and upped the PP to 16mb in it. I'll see what happens.

Oh, I forgot to add before, when I applied this patch yesterday, I also lost my Storage Card when I searched for it. When I tried to check my USB settings, it wouldn't load so I couldn't check or change them.

And, prior to installing this cab, I already had glyphe cache tweaked up, to 2mb I believe.

Edited by tedkord, 11 March 2011 - 02:19 PM.

[ZuinigeRijder]

xlightwaverx, on Mar 9 2011, 12:30, said:

Everything that mentioned has been done, minus the attaching of Samsung apps to relevant shortcuts, but that would take about 15 minutes.  Sense runs fast after all the tweaking is done.  My only issue that I am trying to dissolve is that fact that every once in a while, when the CPU hits 100%, Sense lags a bit (usually at album or weather tabs if you stop a bit) Nothing serious, but I just want to release a Sense ROM with 0 problems, and the caching thing seemed the most relevant because we have the ability to tweak these settings, yet no one seems to have tried it yet.

We have the ability to control three important caching features that gets thrown into the PP.  If Sense is more graphically intensive, then I guess we adjust those cache settings and lower the others.

Seems like a no brainer.  My apologies if I want to share the information with the public instead of hording it for my next release.  I figured you folks would be interested and trying different settings since you all have the how-to (pretty much) and the more of us working on it the better.

X

Maybe this link is interesting:
Sense and high CPU

At least also someone who experienced high CPU with sense, because Album was searching on the SD card........

[xlightwaverx]

ZuinigeRijder, on Mar 12 2011, 09:32, said:

Maybe this link is interesting:
Sense and high CPU

At least also someone who experienced high CPU with sense, because Album was searching on the SD card........

Thanks Z, but I threw those settings in, rebooted, and it's still being a pain.

X

[tedkord]

OK, it looks like something I've got installed is the problem. I upped the PP in AMD's ultralight+sense to 16mb and flashed, then the first thing I installed was your patch - everything worked fine. I don't know if it was any quicker, but it wasn't bogged. Seemed nice and smooth.

Then, I started installing all my ususal stuff, and when I was done, same thing - super slow and laggy, storage card missing, etc...Once I uninstalled the patch, back to normal. SInce it worked initially, I'm assuming it must be a conflict with something I installed.

[xlightwaverx]

xlightwaverx, on Mar 10 2011, 22:32, said:

Same here, 12PP.  Not sure why it is bogging his phone down.

In my research, I have read where changes in these registry settings are only relevant in the boot.rgu file, and remain useless if changed within the system registry.  Is there something done with the boot.rgu that is different than the other registry information that gets added in?  I see drastic changes when I alter these settings, especially glyph*.

Any information would be greatly appreciated.

X

K found this on a Microsoft Blog.

What about these registry keys?

Someone told me that changing the registry keys "CompactionPrio256" and "CompactionCritPrio256" fixes the problem.  Unfortunately, that can't be correct.  There are two things you need to know.  First, in Windows CE, smaller numbers are higher priority.  Compaction defaults to 255, which is the lowest possible priority.  Making the number lower would increase the priority.  That's the opposite of what you think you want to do.

More importantly, though, changing those registry keys doesn't do anything. It is the file system that loads and creates the registry.  But the file system needs some information before the registry is loaded.  So there is a very small bit of data (a "boot strap" registry) that is loaded before the user changeable registry is loaded.  The real versions of these values are in that pre-registry.  The ones you see are kind of like reflections of those real values.  You can change them to your heart's content, but you're only changing the reflection.  You're not changing the actual values the file system uses.  There's no end user way to change the real values.

The good thing is we (chefs) can control what goes into that bootstrap registry (boot.rgu).  Anything that is [HKEY_LOCAL_MACHINE\System\StorageManager\*] is placebo if done manually.  All other settings have a real and true effect.

X

[amdzero]

xlightwaverx, on Mar 13 2011, 21:52, said:

K found this on a Microsoft Blog.

What about these registry keys?

Someone told me that changing the registry keys "CompactionPrio256" and "CompactionCritPrio256" fixes the problem.  Unfortunately, that can't be correct.  There are two things you need to know.  First, in Windows CE, smaller numbers are higher priority.  Compaction defaults to 255, which is the lowest possible priority.  Making the number lower would increase the priority.  That's the opposite of what you think you want to do.

More importantly, though, changing those registry keys doesn't do anything. It is the file system that loads and creates the registry.  But the file system needs some information before the registry is loaded.  So there is a very small bit of data (a "boot strap" registry) that is loaded before the user changeable registry is loaded.  The real versions of these values are in that pre-registry.  The ones you see are kind of like reflections of those real values.  You can change them to your heart's content, but you're only changing the reflection.  You're not changing the actual values the file system uses.  There's no end user way to change the real values.

The good thing is we (chefs) can control what goes into that bootstrap registry (boot.rgu).  Anything that is [HKEY_LOCAL_MACHINE\System\StorageManager\*] is placebo if done manually.  All other settings have a real and true effect.

X

Interesting...

[yieldsign2]

xlightwaverx, on Mar 14 2011, 01:52, said:

K found this on a Microsoft Blog.

What about these registry keys?

Someone told me that changing the registry keys "CompactionPrio256" and "CompactionCritPrio256" fixes the problem.  Unfortunately, that can't be correct.  There are two things you need to know.  First, in Windows CE, smaller numbers are higher priority.  Compaction defaults to 255, which is the lowest possible priority.  Making the number lower would increase the priority.  That's the opposite of what you think you want to do.

More importantly, though, changing those registry keys doesn't do anything. It is the file system that loads and creates the registry.  But the file system needs some information before the registry is loaded.  So there is a very small bit of data (a "boot strap" registry) that is loaded before the user changeable registry is loaded.  The real versions of these values are in that pre-registry.  The ones you see are kind of like reflections of those real values.  You can change them to your heart's content, but you're only changing the reflection.  You're not changing the actual values the file system uses.  There's no end user way to change the real values.

The good thing is we (chefs) can control what goes into that bootstrap registry (boot.rgu).  Anything that is [HKEY_LOCAL_MACHINE\System\StorageManager\*] is placebo if done manually.  All other settings have a real and true effect.

X

This means that your patch has no effect? Or is it not the same registry keys they are talking about.

[xlightwaverx]

yieldsign2, on Mar 15 2011, 12:02, said:

This means that your patch has no effect? Or is it not the same registry keys they are talking about.

The registry keys that deal with "StorageManager" will have no effect, but all others will, like GlyphCache, BPP, Animation, etc.  This thread may turn into a "mild" patch for i920 users, with a boot.rgu section for chefs to use.  

The last two days I have been testing 64kb cache instead of my original 2mb, with a 20mb PP, and this phone is not liking it very much.  Typical Sense lag that I remember even with such a high PP and high GlyphCache.  I will try more tonight.

I am still trying to figure out the damn squishing issue with Sense and it has NOTHING to do with compression or non compressed manila packages, for they do the same thing.  PLEASE ASSIST.

X

[amdzero]

xlightwaverx, on Mar 15 2011, 20:12, said:

The registry keys that deal with "StorageManager" will have no effect, but all others will, like GlyphCache, BPP, Animation, etc.  This thread may turn into a "mild" patch for i920 users, with a boot.rgu section for chefs to use.  

The last two days I have been testing 64kb cache instead of my original 2mb, with a 20mb PP, and this phone is not liking it very much.  Typical Sense lag that I remember even with such a high PP and high GlyphCache.  I will try more tonight.

I am still trying to figure out the damn squishing issue with Sense and it has NOTHING to do with compression or non compressed manila packages, for they do the same thing.  PLEASE ASSIST.

X

Can you list the packages you use?  I'm using mostly LEO, but I have some oboe and huasan packages as well.

[xlightwaverx]

amdzero, on Mar 15 2011, 22:51, said:

Can you list the packages you use?  I'm using mostly LEO, but I have some oboe and huasan packages as well.

Umm, latest HD2 release from TMOUS now, still same issue.
Originally all 1920.2525 releases.  I think I am going to go back because I think its way faster than this HD2 version.

Didn't we solve this already AMD?  I could have sworn you told me Chainfire made specific OpenGL patches for Manila or something...  I thought it was figured out back when Steel posted SteelSense.

I am at WITS END!  I can't even get an answer from the 8000 forum.  

X

[amdzero]

xlightwaverx, on Mar 16 2011, 16:45, said:

Umm, latest HD2 release from TMOUS now, still same issue.
Originally all 1920.2525 releases.  I think I am going to go back because I think its way faster than this HD2 version.

Didn't we solve this already AMD?  I could have sworn you told me Chainfire made specific OpenGL patches for Manila or something...  I thought it was figured out back when Steel posted SteelSense.

I am at WITS END!  I can't even get an answer from the 8000 forum.  

X

We did fix it, and it is fixed in my sense roms. however this issue isn't entirely the opengl problem. There seems to be a few packages that still cause this issue (and none of them have images so CFC is out).